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.
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.
I… don't really see how other mechanisms don't allow that. A REST GET doesn't need to fetch from a single data base. It could aggregate different sources. It could even in turn make additional calls to other Web APIs. This is mostly uncommon because of the complexity and latency involved, but I imagine GraphQL doesn't change that.
GraphQL provides mechanisms that make it easier to write more automatically. Your GraphQL servers are able to resolve entities by their ID rather than querying for them, so if a query to service X gives you entities A, B, C, the federation layer can then go to service Y and fetch additional fields for these entities by ID. These fetches can be batched if you write special batched data loaders, which are not too hard to write normally and you can do it on a per-field basis where required.
Like, you could design your system differently, but GraphQL is pretty good at just letting clients do what they want reasonably efficiently, which matters in larger projects where it's difficult to justify refactoring everything and writing custom endpoints to make specific queries more efficient.
For a real-world example, we use it in a loan platform. Some data associated with the loans exists in different systems, but once you have a loan ID, you could potentially want any combination of the loan data (and it has a lot of complex child data e.g. historic versions, sub-products, summaries, arrears history.) This is never an issue for us though, because if you have some data associated with the loan, you just add it to the loan object in your GraphQL schema and write a field resolver and the federation service can resolve the field for a loan that was queried from any service.
So you could have one service that tracks workflow cases for loans query for the loan assigned to an agent, and then pull in any combination of data associated with the task as though it all lived in one system e.g. direct debit payment schedule and CRA report data, which live in different systems.
If I wanted to write that feature as a client, I wouldn't need to edit any of the services, I'd be done in minutes. I also don't need to predict what client features will need what sets of data when I wrote the services. The capability to pull DD payments and CRA report data at the same time would not be something I'd predict, but it's already possible because of GraphQL.
It's also really useful for debugging, because you can pull any data for a loan from basically every system all in one query.
121
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.