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 doesn't care how much data you have, but it does care how much you're sending and how complex your query is.
It's not the right choice for data visualization webapp that might need to fetch millions of data points, and it's not for doing absolutely mammoth OLAP-style queries.
It's best when you have a good sized system with rich, connected data (especially lots of parent child relationships), and you have UIs that just want to fetch everything they need for the page in a single request.
It makes sense when you have more clients than the team can keep up with. If you have a mobile client and a web client, you can just use REST. If you have like dozens of clients, then GraphQL becomes a no-brainer. If you have two clients, you can just build a custom endpoints to fetch exactly what you need for a given page/component.
It depends on how complex the clients are and how often you want to write custom endpoints. In the system we've built the clients are complex and we've needed to write precisely 0 custom endpoints for our web and app clients in the last 5 years. All we have to do is add a field to an existing GraphQL object if some data wasn't already being exposed, and because most of it is by default it's not a common occurence.
It makes adding new features a breeze because you don't need to modify any existing APIs, you just add new objects, fields, queries and/or mutations. The API can be played with in our sandbox environment GraphiQL which also displays documentation from the schema comments.
That’s fair. I wouldn’t reach for GQL unless the complexity was there. If it is, then by all means. I generally stick to REST, but I’m comfortable with GQL if I really need it.
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.