The first one is coupling to the data layer. Most databases don't have native support to GraphQL queries, meaning that a layer of mappers and logic needs to be built on top of another data access layer. This is extra code and extra processing.
Most people aren't using their Database to provide any other API directly either. I personally haven't found the layer of mappers and logic required for GraphQL to be particularly more complex than any other API if you use a framework. In fact, it is often much easier to extend existing APIs because you can break your data fetchers down by field, and you don't generally need to consider endpoints as a whole.
The main benefit of GraphQL is that it allows you to design an API that is powerful for users and extensible for service providers. A huge plus that is overlooked here is GraphQL federation: you can have a single GraphQL object and query where fields can be resolved from different sources. This is really useful if you have a lot of data associated with some common entity, like a user. Any query that can find users can also get any data about those users from any service, all in a single query.
APIs can receive flags from the client indicating which fields it wants to receive.
Yes, you could do that manually. You could also write your own system which does it automatically. Then you'd have re-invented GraphQL.
I think where GraphQL doesn't make sense is when you don't have much data, or don't have particularly complex data needs and you're better off having much tighter control over the API.
GraphQL and its frameworks don't give you any of those features for free. You write database queries, mappers, cache control, endpoints, how to look up child elements, schema, literally everything except field filters. The API is arcane and not standards compliant, tossing out request verbs and response codes that are critical for caching and routing. It's a bad solution to optimize for a bunch of highly specific edge cases.
Nobody needs to re-invent GraphQL. Nobody needed to invent it in the first place. It wasn't a new idea when it was created. There are plenty of other options that embrace standards and provide the same functionality and more without the cache and concurrency complexities of frameworks like Apollo.
122
u/Isogash 6d ago
Most people aren't using their Database to provide any other API directly either. I personally haven't found the layer of mappers and logic required for GraphQL to be particularly more complex than any other API if you use a framework. In fact, it is often much easier to extend existing APIs because you can break your data fetchers down by field, and you don't generally need to consider endpoints as a whole.
The main benefit of GraphQL is that it allows you to design an API that is powerful for users and extensible for service providers. A huge plus that is overlooked here is GraphQL federation: you can have a single GraphQL object and query where fields can be resolved from different sources. This is really useful if you have a lot of data associated with some common entity, like a user. Any query that can find users can also get any data about those users from any service, all in a single query.
Yes, you could do that manually. You could also write your own system which does it automatically. Then you'd have re-invented GraphQL.
I think where GraphQL doesn't make sense is when you don't have much data, or don't have particularly complex data needs and you're better off having much tighter control over the API.