GraphQL forms a strongly and deliberately typed interface between a client and server, without frontend and backend teams having to collaborate on the shape of the endpoints (should such and such endpoint gain new options? should it be split into a separate endpoint? should the old one be deprecated, and if so, do clients still rely on it?).
Instead, they need only agree on the shape of the data available, and the frontend queries it however it needs to be queried while the backend resolves the nested calls with no additional effort* from those writing the backend.
Also, some clients come with additional affordances for hard problems, like pagination.
* okay, fine, you have to wrap your data resolution in Dataloaders, but that's not particularly challenging
* in my experience you basically have to write every call anyway, in other words, getting GraphQL set up on the backend is at least as much work as writing API boilerplate. Again, correct me if I am wrong. It's been a while since I last used GraphQL and I keep hearing about hearing about magic libraries that make it "effortless".
I abstain from writing graphql apis now because they’re too much work for me when toy apps are simple and I can render json.
But if a team does want graphql without the fuss of openapi, json schemas, and swagger docs, I recommend tools like Hasura that autogenerates graphql apis over my db. Auto generation of graphql resolvers are the way to go for productivity. Supabase even created a Postgres extension to perform graphql directly within postgres https://supabase.com/blog/2021/12/03/pg-graphql
Comments
GraphQL forms a strongly and deliberately typed interface between a client and server, without frontend and backend teams having to collaborate on the shape of the endpoints (should such and such endpoint gain new options? should it be split into a separate endpoint? should the old one be deprecated, and if so, do clients still rely on it?).
Instead, they need only agree on the shape of the data available, and the frontend queries it however it needs to be queried while the backend resolves the nested calls with no additional effort* from those writing the backend.
Also, some clients come with additional affordances for hard problems, like pagination.
* okay, fine, you have to wrap your data resolution in Dataloaders, but that's not particularly challenging
* in my experience you basically have to write every call anyway, in other words, getting GraphQL set up on the backend is at least as much work as writing API boilerplate. Again, correct me if I am wrong. It's been a while since I last used GraphQL and I keep hearing about hearing about magic libraries that make it "effortless".
I abstain from writing graphql apis now because they’re too much work for me when toy apps are simple and I can render json.
But if a team does want graphql without the fuss of openapi, json schemas, and swagger docs, I recommend tools like Hasura that autogenerates graphql apis over my db. Auto generation of graphql resolvers are the way to go for productivity. Supabase even created a Postgres extension to perform graphql directly within postgres https://supabase.com/blog/2021/12/03/pg-graphql
Thanks for the info!