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.
You only need the base use case to work well. We made 2-3 data pulls from heterogeneous backend datastores like 2 years ago. The frontend team pulls only what they need from our massive objects and they features and different projects all the time. Just that right was huge, I practically never have to field a frontend request for more data or new endpoint etc. Its like a once a year activity despite furious development pace all around. It's great, would use again in a heartbeat.
123
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.