3 ms·

When I started in webdev a decade ago, every data change needed for the frontend was a job sent to the backend, usually to make a small change in a controller.

When I started in webdev a decade ago, every data change needed for the frontend was a job sent to the backend, usually to make a small change in a controller. The turnaround was a minimum of three days and a new page could take weeks. Now the frontend gets almost all data through graphql, and happily write and update their own queries without the backend knowing or caring about it unless there's a question or bug or an extension needed to the api. They iteratively design queries with history and docs and autocomplete on graphiql. This is a huge time saver all around. We could have wrapped our platform in rest apis instead, but compared to graphql it would be like a bookstore that sold paragraphs rather than books.

bradstewart 5y ago
> The turnaround was a minimum of three days and a new page could take weeks. I think you finally convinced me that GraphQL does have a legitimate use case. Every time I evaluated building a GraphQL API, it had all of the complexity of the REST(ish) counterpart, and then some. But where you put that complexity could have big impacts in a multi-team environment, particularly if it reduces round trips between teams. This is basically my view on microservices as well (technical "solution" to an organizational issue), thanks for making me finally notice the parallel here!
- tomnipotent 5y ago
  Facebook was also running into issues where the API was diverging between iOS and Android based on their specific payload needs. Could either maintain two REST API's, or a single API that allowed each app to meet their needs without impacting release velocities.
- marcolussetti 5y ago
  Agreed, I think I'm finally getting what it's for, and the grandparent post and this post made me want to try GraphQL actually! It's interesting how now that it's explained this way, it's so hard to unsee it, yet it never even got close to clicking before.

bradstewart 5y ago

> The turnaround was a minimum of three days and a new page could take weeks. I think you finally convinced me that GraphQL does have a legitimate use case. Every time I evaluated building a GraphQL API, it had all of the complexity of the REST(ish) counterpart, and then some. But where you put that complexity could have big impacts in a multi-team environment, particularly if it reduces round trips between teams. This is basically my view on microservices as well (technical "solution" to an organizational issue), thanks for making me finally notice the parallel here!

tomnipotent 5y ago
Facebook was also running into issues where the API was diverging between iOS and Android based on their specific payload needs. Could either maintain two REST API's, or a single API that allowed each app to meet their needs without impacting release velocities.
marcolussetti 5y ago
Agreed, I think I'm finally getting what it's for, and the grandparent post and this post made me want to try GraphQL actually! It's interesting how now that it's explained this way, it's so hard to unsee it, yet it never even got close to clicking before.