4 ms·

GraphQL is above all, just an optimization. It optimizes the amount of bytes sent over the network. I'm very happy with REST APIs (maturity level 2/3) and see

GraphQL is above all, just an optimization. It optimizes the amount of bytes sent over the network. I'm very happy with REST APIs (maturity level 2/3) and see no reason to change as we've never had performance issues. Most companies are not Facebook with 1 billion customers. The fact that clients can compose their own queries brings nothing new, as you still have to allow these capabilities on your server, just like with REST; you have to code against all the possible variations (primary resources, filters, sorts, etc) and optimize the DB/remote reads. So no, the users have no more freedom, the server remains the limiting factor. The way it lets you compose queries is nice for developers, but you can very easily do that with a single aggregation REST endpoint too, provided you have resource links in your responses (which also makes it nice to use with human tools like POSTman) and you can still cache the individual REST responses with Varnish, etc. Doing Subscriptions or mutations over GrapQL brings very little benefits. In fact, it's even dangerous as most system shouldn't allow multiple mutations per request. The whole "just cache it on the client" is a big joke and many people seem to underestimate getting caching right. The default in Relay used to be "cache forever", this can't be serious. You could only do that if the current user was the only person able to modify the data or if you could guarantee a perfect synchronization with the server via continuous events and that's actually pretty hard to get right and generally a big investment. In practise, most apps/sites don't work like that. I'm not sure what that leaves? "Free" barebone documentation? You can have that too with a good type system (e.g scala's) albeit with a lot more work but with a much nicer type system / expressivity. I mean, I get why it's popular, but the thing's totally blown out of proportion.

mej10 9y ago
Do you have good examples of > easily do that with a single aggregation REST endpoint too, provided you have resource links in your responses I work with/on a "REST" API that has about 20 types of objects, 5-100 fields on each, with many different relationships between them. We've been looking at GraphQL to solve both the querying and mutation aspect, since it is extremely cumbersome to do it efficiently. GraphQL seems great for this case, but if there is some way just adding resource links could get us most of the benefits I'd love to hear it!
- boubiyeah 9y ago
  This is a POC in scala I put together rather quickly: https://github.com/AlexGalays/POC-api-aggregation https://github.com/AlexGalays/POC-api-aggregation How you would write a query: https://github.com/AlexGalays/POC-api-aggregation/blob/master/app/views/index.scala.html#L19 https://github.com/AlexGalays/POC-api-aggregation/blob/maste... Unfortunately the PokeAPI is not the best at showcasing this with many level of unneeded nesting and resources with nothing but an "url" property but hopefully you get the idea :) The fact that the query "language" is indendation based rather than GraphQL's a-string-that-looks-a-bit-like-json-but-isnt was just an arbitrary choice, it's easy to change.
Touche 9y ago
Can't upvote this enough. From what I've read it sounds like GraphQL solves a problem at Facebook where they have so many people working on related data at the same time that they started seeing duplicate API endpoints, and duplicate requests for the same data from different parts of the team. GraphQL provides a chokepoint to prevent that from occurring. Makes total sense at that scale. Why startups are adopting this without that sort of problem, I have no idea. Because the query syntax is pretty?
- deleted 9y ago
  [deleted]
- CodesInChaos 9y ago
  A huge selling point for me is that the client explicitly enumerating all fields they're interested in allows targeted deprecation warnings and finely grained usage statistics.
  - boubiyeah 9y ago
    That's nice yes. Isn't it rare to deprecate fields though? And you can't be sure some of your clients are not overfetching "for convenience / just in case", especially if they don't use the full suite of Facebook libs.
  - Touche 9y ago
    Another thing that sounds worthy when working on gigantic teams and less so when at a startup / small company.
    - abritinthebay 9y ago
      Chose the right tech early and you’ll have less growth pain. I can’t tell you the number of startups I’ve seen that spend time thrashing on their REST APIs who would be better off using GraphQL as the consumable interface. Would have made many companies supplication development go WAY smoother
djmashko2 9y ago
(Author of the post here) > GraphQL is above all, just an optimization. It optimizes the amount of bytes sent over the network. This was a common thought when GraphQL was first announced, but working with organizations that are adopting it we've found just the opposite: It's actually the tooling and development velocity benefits that people get the most value of. It's kind of like if you could design your API to be super orthogonal and fine-grained, while still getting the optimized network transport of hand-coded endpoints for each view. > The whole "just cache it on the client" is a big joke and many people seem to underestimate getting caching right. The post goes over a new architecture specifically for server-side caching. Caching on the client is definitely not sufficient! And Relay isn't the way most people are doing GraphQL today. Also, clients are about to start supporting cache control and TTLs, making life a lot easier. I'm curious what the comparison here is, since people using technologies like Redux with REST APIs are also usually caching responses forever. This is really useful feedback for those of us that think GraphQL is going to be a super important technology going forward, and I hope you give it another shot in a year or two! It's still pretty fresh, especially compared to REST, but I think it will improve quickly :]
- boubiyeah 9y ago
  Thanks for your reply. I've not ditched graphQL forever, but there's a lot of buy-in involved for what it could give me right now. The tech is quite intrusive on your web server. I didn't know people using redux also cached responses forever, that seems beyond naive to me :)
  - djmashko2 9y ago
    Note that "forever" here means "for as long as this specific browser tab is open", both for GraphQL and for Redux.
jrs95 9y ago
It really isn't just an optimization, though. I actually work at a relatively small team (< 10 developers) and we're having a lot of success with GraphQL. For a variety of reasons we ended up moving to a microservices approach, and GraphQL has worked great for us for aggregating those services. It's not much more work than what a REST API with Swagger docs would be, but the tooling is a lot better and the schema is much more powerful. With a REST API, we would just have a bunch of endpoints and some basic code generation as a time saver for clients. With a GraphQL schema, we have the relationships between all of our data well defined and it's super easy to continue adding onto. There's more of an upfront investment, but I'm pretty confident it's already saved us time. At the same time, I agree that it's overly hyped. It's not some magic bullet, and there's definitely a learning curve. It's a really powerful tool though, much more than just an optimization.

mej10 9y ago

Do you have good examples of > easily do that with a single aggregation REST endpoint too, provided you have resource links in your responses I work with/on a "REST" API that has about 20 types of objects, 5-100 fields on each, with many different relationships between them. We've been looking at GraphQL to solve both the querying and mutation aspect, since it is extremely cumbersome to do it efficiently. GraphQL seems great for this case, but if there is some way just adding resource links could get us most of the benefits I'd love to hear it!

boubiyeah 9y ago
This is a POC in scala I put together rather quickly: https://github.com/AlexGalays/POC-api-aggregation https://github.com/AlexGalays/POC-api-aggregation How you would write a query: https://github.com/AlexGalays/POC-api-aggregation/blob/master/app/views/index.scala.html#L19 https://github.com/AlexGalays/POC-api-aggregation/blob/maste... Unfortunately the PokeAPI is not the best at showcasing this with many level of unneeded nesting and resources with nothing but an "url" property but hopefully you get the idea :) The fact that the query "language" is indendation based rather than GraphQL's a-string-that-looks-a-bit-like-json-but-isnt was just an arbitrary choice, it's easy to change.

Touche 9y ago

Can't upvote this enough. From what I've read it sounds like GraphQL solves a problem at Facebook where they have so many people working on related data at the same time that they started seeing duplicate API endpoints, and duplicate requests for the same data from different parts of the team. GraphQL provides a chokepoint to prevent that from occurring. Makes total sense at that scale. Why startups are adopting this without that sort of problem, I have no idea. Because the query syntax is pretty?

deleted 9y ago
[deleted]
CodesInChaos 9y ago
A huge selling point for me is that the client explicitly enumerating all fields they're interested in allows targeted deprecation warnings and finely grained usage statistics.
- boubiyeah 9y ago
  That's nice yes. Isn't it rare to deprecate fields though? And you can't be sure some of your clients are not overfetching "for convenience / just in case", especially if they don't use the full suite of Facebook libs.
- Touche 9y ago
  Another thing that sounds worthy when working on gigantic teams and less so when at a startup / small company.
  - abritinthebay 9y ago
    Chose the right tech early and you’ll have less growth pain. I can’t tell you the number of startups I’ve seen that spend time thrashing on their REST APIs who would be better off using GraphQL as the consumable interface. Would have made many companies supplication development go WAY smoother

djmashko2 9y ago

(Author of the post here) > GraphQL is above all, just an optimization. It optimizes the amount of bytes sent over the network. This was a common thought when GraphQL was first announced, but working with organizations that are adopting it we've found just the opposite: It's actually the tooling and development velocity benefits that people get the most value of. It's kind of like if you could design your API to be super orthogonal and fine-grained, while still getting the optimized network transport of hand-coded endpoints for each view. > The whole "just cache it on the client" is a big joke and many people seem to underestimate getting caching right. The post goes over a new architecture specifically for server-side caching. Caching on the client is definitely not sufficient! And Relay isn't the way most people are doing GraphQL today. Also, clients are about to start supporting cache control and TTLs, making life a lot easier. I'm curious what the comparison here is, since people using technologies like Redux with REST APIs are also usually caching responses forever. This is really useful feedback for those of us that think GraphQL is going to be a super important technology going forward, and I hope you give it another shot in a year or two! It's still pretty fresh, especially compared to REST, but I think it will improve quickly :]

boubiyeah 9y ago
Thanks for your reply. I've not ditched graphQL forever, but there's a lot of buy-in involved for what it could give me right now. The tech is quite intrusive on your web server. I didn't know people using redux also cached responses forever, that seems beyond naive to me :)
- djmashko2 9y ago
  Note that "forever" here means "for as long as this specific browser tab is open", both for GraphQL and for Redux.

jrs95 9y ago

It really isn't just an optimization, though. I actually work at a relatively small team (< 10 developers) and we're having a lot of success with GraphQL. For a variety of reasons we ended up moving to a microservices approach, and GraphQL has worked great for us for aggregating those services. It's not much more work than what a REST API with Swagger docs would be, but the tooling is a lot better and the schema is much more powerful. With a REST API, we would just have a bunch of endpoints and some basic code generation as a time saver for clients. With a GraphQL schema, we have the relationships between all of our data well defined and it's super easy to continue adding onto. There's more of an upfront investment, but I'm pretty confident it's already saved us time. At the same time, I agree that it's overly hyped. It's not some magic bullet, and there's definitely a learning curve. It's a really powerful tool though, much more than just an optimization.