Wait, people are using graphql for private, not exposed, backend apis?
Who would torture themselves like that?
Isn't the whole point that your frontend can make the exact queries it needs and load the exact data it needs?
Namely, last I checked, client libraries for working with graphql are only good with JS. I tried working with graphql a few years ago in python and the only two client libraries absolutely sucked. Server libraries were great, but python clients sucked, badly. I ended up writing bare requests with a hardcoded heredoc for the query and endless square brackets to get the fields for the little data I needed.
Maybe the situation improved dramatically in the last three years, but I can't imagine so dramatically.
I wouldn't pick graphql as a private backend API in a million years. Well, maybe if ever single service was written in nodejs with no possibility of using other languages.
I remain unconvinced that GraphQL is the tech we should have chosen, but we’re using it privately to mesh together subgraphs from different teams’ various areas of concern and it seems to be working pretty well. There’s been talk of opening it up to clients, but the idea of trying to apply a permission/access control layer is nightmare material.
As for language support, I’ve used a couple of libraries on both the client and server side for both Go and PHP, and they seem pretty good. JavaScript/TypeScript definitely seem to be the first-class citizens though.
It's not really torture. I do. I have built a private federation API in a system where there's a "mothership" service that needs to talk to individual websites.
Those websites are WordPress at the moment but they may be Magento, PrestaShop or whatever in the future.
GraphQL means I can template the API calls used to keep them in sync with the mothership. It's awesome.
I also use it for the frontend/backend connection of a couple of admin APIs and an intranet app.
Nuxt frontends, Laravel/Lighthouse headless backends. The only pain point is the unnecessarily complex Apollo stuff in the client, but that gives you really nice smart queries in Nuxt 2; it may not be that crucial in Vue 3/Nuxt 3.
> that gives you really nice smart queries in Nuxt 2; it may not be that crucial in Vue 3/Nuxt 3.
It's even better with Vue 3 (or Vue 2 with the composition API anyway), especially when you combine it with graphql-codegen. Smart queries become just another composable, no `this.$apollo` to be seen. Got that going with API Platform on the backend myself, which has really nice integration with symfony, though it speaks only a bare-bones dialect of graphql as opposed to Lighthouse with all its crazy directives. No persisted queries either, but it's an internal app with bandwidth to burn.
Been eying wp-graphql for my one wordpress project. From my dabbling with it, the DX feels a lot nicer than the WP REST api, though I'm sure you know that's an awfully low bar to clear.
You’d be amazed at how much self-inflicted difficulties developers are willing to subject themselves to in the name of doing things in the same way that a FAANG does.
Graphql is by far the most painful DX and least productive thing I've seen cargo-culted. Like most things there's a time and place for Graphql but I think it's vastly overused.
For backend services in particular literally anything else is probably a better choice - rest, grpc, soap, a socket. I honestly don't know why more people don't give twirp a shot.
Pothos + graphql Zeus gives us the ability to expose a prisma like interface to the clients with the ability to curate what fields are exposed and maintain the ability to setup field level security.
Oh, and we get DB schema to frontend propagation of changes to the type.
This is by far the best experience I have had for private APIs - Where we don't need to maintain backwards compatability.
I do get that the HN crowd is super adverse to graphql, but I fail to see other arguments than matters of taste.
Would you consider this solution for a public (enterprise/B2B, not public-on-the-internet-for-anyone) API? I may need to build a public API that lets customers select certain fields from a variety of objects with many fields.
We use it for an application that aggregates data for consumption by several different teams that all consume different subsets of the data. When you have a pretty simple use-case it's really not that bad to get a decently functioning API off the ground, and because it's self-documenting we can spend our time on more mission critical work.
You want to execute a single query for a given page for performance. But whether a field is included in the query should depend on whether a component uses that field. If you write the raw query without fragments, you introduce implicit coupling between the query declaration and the subcomponents, which (like with REST endpoints, CSS classes, etc) means the query becomes append-only. Removing fields is dangerous and requires research, which devs on a Friday won’t do. Especially if you’re making changes to a component used across many pages.
Okay, so write fragments. However, without a framework like Relay (and soon Apollo), you still receive, at runtime, the entire network response. ie there is no masking at the fragment level. This means that there still is an implicit dependency between components, and removing fields is still dangerous.
I used to think like you. Until I used and understood the Relay GraphQL library. The learning curve is a bit steep. But if you are consuming a lot of GraphQL data in a web browser, this is totally worth the investment.
GraphQL really shines with data intensive applications where you need pagination, filtering, sorting, projections etc.
Normalized caching, pagination, and code generation are some features that many developers find appealing and are supported out of the box by many GraphQL clients.
As the current maintainer of graphql-python/gql, the most popular python client, I have to say that you should definitely try again to get an accurate opinion. A lot of changes have been made around that time and we are quite feature-full and stable right now, with 100% code coverage and good documentation.
I think there is some confusion with the term 'public' here.
The Graphql server itself is still publicly exposed to the internet, but the ability to query is not. Queries have to be whitelisted ahead of time (persisted queries).
I wrote a series of backend, internal GraphQL APIs. I think the argument of "make the exact queries it needs and load the exact data it needs" actually applies _more_ to internal APIs than to frontends, where I personally prefer a well schema'd BFF pattern. We did face some performance issues with some of the server libraries, unfortunately, but the backend development team were extremely productive in comparison to supporting multiple API shapes.
> backend APIs
Using GraphQL for service-to-service communication isn’t the sweet spot if you can deploy both services together. Rather, it’s great if the services are deployed on their own schedule. This is the case if one service is someone’s browser, where forcing a refresh whenever the backend is redeployed isn’t tenable. For service-to-service communication, where you can deploy both together, gRPC or something is a better option.
I think the public/private distinction here is more in "officially allowed for public use" vs "API your frontend uses but is not documented for public use". Obviously security is still a thing, but having good ergonomics for your frontend devs means your frontend devs can just work forward and backend people can focus on other things instead of going back and forth on perf issues downstream of REST APIs
> and backend people can focus on other things instead of going back and forth on perf issues downstream of REST APIs
Instead they now focus on perf problems of downstream federated GraphQL queries. And query complexity. And unbounded queries. And extreme overfetching of data that all clients inevitably do. And...
This is nonsense. GraphQL queries are simple HTTP requests, with no more complexity than REST. You POST a query string and some JSON and it’s done. If your client makes it harder than that, don’t use it.
Here’s my workflow for creating an API with Postgraphile:
create view graphql.object as select some,columns from table;
(That’s it)
It’s trivial to query it with curl, I’d give an example but I’m afk rn.
I’ve been using GraphQL for about the same amount of time as in the article and it solved a bunch of problems for me.
It’s so easy to use, and saves so much time - once you spend the time to understand it.
I've veen reading about graphql forever and never understood it. Your comment finally made it click for me. Do you happen to have any more documentation around your method of working?
> This is nonsense. GraphQL queries are simple HTTP requests, with no more complexity than REST. You POST a query string and some JSON
The complexity of GraphQL in fact begins there, and also sort of explains a lot of why GraphQL is all but simple:
Why am I using a query language instead of just passing an AST via JSON, a data format every general purpose language supports very well these days?
The answer to the above question, and most of GraphQLs other complexities: Some arbitrary design decision.
Another example:
GraphQL could've easily been expressed as a REST API, even an Open API. From what I have seen, with the help of VC backing and FAANG endorsement, GraphQL mostly rose to replace JSON:API, which accomplishes pretty much all of the same goals in just JSON (and is RESTful).
One big issue of GraphQL is also that API clients tend to suck. That's not a problem for OpenAPIs.
And again, why is this the case? Some arbitrary design decision.
I feel like in general, someone creating a new DSL where it's not needed (and is obviously designed to look cool rather than actually be expressive), is a good sign they're just writing the software to stroke their ego rather than reach a meaningful end.
That's why in all the promo material for GraphQL you only see the query language, and not all of the actual setup required to send a request or even what an actual GraphQL HTTP request looks like. GraphQL, the framework, is not actually as simple and elegant as GraphQL the query language attempts to portray it as.
It's almost like someone came up with a query language for fun then came up with all the details of how a web server would utilize it afterwards.
Even today, GraphQL markets itself only as a query language (A query language for your API). When, as you have already mentioned, it is more than that.
That's why most developers know vaguely what GraphQL is ("Oh, that one language") but not how it actually works in practice. And when they actually encounter it, it feels almost like a betrayal, because it's nowhere near as simple, sleek or elegant as all the marketing they saw suggested.
At least, this was my experience when having to deal with a
third party GraphQL API (funny enough, they migrated from REST, see ShipHero).
A lot of people in this thread are criticizing GraphQL.
The reality is that GraphQL is a great tool for one job: building APIs that scale across thousands of engineers, billions of users, and many megawatts of machines. This is what we use GraphQL for at Meta.
To make it work well, it takes dedicated teams building infrastructure that makes the DevX great. It takes many years to build this out across various backends, clients, and internal tools. We have open sourced some of this infra — the GraphQL spec, Relay, GraphiQL, etc.
But there are many tools we built that we have not open sourced yet, largely because they’re tightly coupled to our internal ORMs, runtimes, error handling, authentication and security systems, and so on. I wish we open sourced more of our GraphQL stack, so more people could experience the awesome DevX we have internally.
At the same time, GraphQL is a tool. No tool can be used all the time for everything. Meta’s 3rd party APIs still use REST for this reason; some internal services use Thrift; etc.
It’s up to you to evaluate the tools available to build the way that makes sense for your business. Because some parts are available off the shelf, but others often need to be built in house, it is up to you to understand that cost and evaluate whether it is worth it for your use cases.
My hope is that as time goes on, more dev tools startups come in the fill the gap in tooling around client libraries, auth, security, and so on to make GraphQL a good choice at smaller scales, too. The DevX is that good when you get it right.
GraphQL is particularly useful for data intensive applications. That is what we use it for. I frequently see people try to use it for simpler applications and give up quickly because it does have a steep learning curve, if you are trying to do it right both on server and client.
Eight Years of GraphQL, and I have yet to find a single use case for it in my projects. I've had to interact with external GraphQL APIs a few times and each time it has been a terribly painful experience. Funnily enough, for the few queries where GraphQL would've actually been useful to get some deeply nested data structure, it was usually impossible to use it because the "query is too big/deep" or it had cycles
One of the useful things I learned from a professor at my university is that every technology is good enough for its own use case. I still don't understand why certain engineers don't get this and go from "XYZ is awesome, I use it everywhere" to "I'm over XYZ."
Just like the title of the article suggests, GraphQL is great, but ONLY in the right context.
I have yet to find an alternative to the GraphQL protocol that has the following requirements:
- Good support for HTTP 1.1
- Provides typesafe contracts for queries and mutations
- Strong support for most common UI clients (JS/React Native/SwiftUI)
- Backend can be written in a language that isn't JavaScript/TypeScript
- Large developer community
Closest thing I've found is defining your schema using OpenAPI spec, and using tools to generate code from that source for the client and server, but this is a much worse DX than the process of defining GraphQL schemas.
I never understood the point. Really don't. GraphQL does not provide any built-in mechanisms for filtering, sorting, pagination or other arbitrary transformations of the response. If you are already built those then might as well just include the data necessary and use a REST API.
It depends on whether your chosen platform can do it.
If you're coding resolvers by hand, that is not fun. But for example the Lighthouse GraphQL layer for Laravel (it's a schema-first thing based on the Webonyx PHP GraphQL reference implementation) can do a lot of this for you using schema decorations.
It has where/filter/sort/pagination, automatic scope narrowing etc., and you have very little code (if any) beyond the graphql schema to set it up. It integrates brilliantly with the Eloquent query builder.
One of the best applications for PHP IMO; it is really enormously productive.
> GraphQL does not provide any built-in mechanisms for filtering, sorting, pagination or other arbitrary transformations of the response.
GraphQL is just the protocol. It is up to implementations to add support for it. We use Hot Chocolate GraphQL server with entity framework backend, and it has built-in support for all of those things.
Vast majority of the criticism of GraphQL comes from people who do not understand it. GraphQL does have a steep learning curve.
GraphQL, but more specifically GraphQL Federation solves an organisational problem. With Federation, teams can collaborate on building an API together with a Schema Registry and Composition Checks across all Subgraphs (Services), which is a unique enabler in the market.
We've got a lot of customers in the enterprise segment and it's growing rapidly to the point where I'd say it's becoming an enterprise standard.
The breaking changes part from the original article was clear to me. The author was saying that if you control the API and the client, it’s often quicker to release changes that are not backwards compatible as long as you can coordinate the release of the two. Then there’s no need to version at all. Sounds like this is harder with graphql than REST.
Certainly, if you can either force your clients to refresh their browsers or can tolerate clients breaking, that works! That might work great for internal tools, for example (as long as no work is lost when you refresh, or you can just expect your employees to redo the work). But it’s not tenable for anything that customers use.
Readit News
Who would torture themselves like that?
Isn't the whole point that your frontend can make the exact queries it needs and load the exact data it needs?
Namely, last I checked, client libraries for working with graphql are only good with JS. I tried working with graphql a few years ago in python and the only two client libraries absolutely sucked. Server libraries were great, but python clients sucked, badly. I ended up writing bare requests with a hardcoded heredoc for the query and endless square brackets to get the fields for the little data I needed.
Maybe the situation improved dramatically in the last three years, but I can't imagine so dramatically.
I wouldn't pick graphql as a private backend API in a million years. Well, maybe if ever single service was written in nodejs with no possibility of using other languages.
As for language support, I’ve used a couple of libraries on both the client and server side for both Go and PHP, and they seem pretty good. JavaScript/TypeScript definitely seem to be the first-class citizens though.
In your case of many disparate services, the nightmare is just the same with REST.
It's not really torture. I do. I have built a private federation API in a system where there's a "mothership" service that needs to talk to individual websites.
Those websites are WordPress at the moment but they may be Magento, PrestaShop or whatever in the future.
GraphQL means I can template the API calls used to keep them in sync with the mothership. It's awesome.
I also use it for the frontend/backend connection of a couple of admin APIs and an intranet app.
Nuxt frontends, Laravel/Lighthouse headless backends. The only pain point is the unnecessarily complex Apollo stuff in the client, but that gives you really nice smart queries in Nuxt 2; it may not be that crucial in Vue 3/Nuxt 3.
It's even better with Vue 3 (or Vue 2 with the composition API anyway), especially when you combine it with graphql-codegen. Smart queries become just another composable, no `this.$apollo` to be seen. Got that going with API Platform on the backend myself, which has really nice integration with symfony, though it speaks only a bare-bones dialect of graphql as opposed to Lighthouse with all its crazy directives. No persisted queries either, but it's an internal app with bandwidth to burn.
Been eying wp-graphql for my one wordpress project. From my dabbling with it, the DX feels a lot nicer than the WP REST api, though I'm sure you know that's an awfully low bar to clear.
For backend services in particular literally anything else is probably a better choice - rest, grpc, soap, a socket. I honestly don't know why more people don't give twirp a shot.
https://github.com/twitchtv/twirp
Oh, and we get DB schema to frontend propagation of changes to the type.
This is by far the best experience I have had for private APIs - Where we don't need to maintain backwards compatability.
I do get that the HN crowd is super adverse to graphql, but I fail to see other arguments than matters of taste.
Okay, so write fragments. However, without a framework like Relay (and soon Apollo), you still receive, at runtime, the entire network response. ie there is no masking at the fragment level. This means that there still is an implicit dependency between components, and removing fields is still dangerous.
That’s why you need Relay.
I make that case here - https://youtu.be/lhVGdErZuN4?si=tOJNWl-j-Uj28RUs
GraphQL really shines with data intensive applications where you need pagination, filtering, sorting, projections etc.
The Graphql server itself is still publicly exposed to the internet, but the ability to query is not. Queries have to be whitelisted ahead of time (persisted queries).
Instead they now focus on perf problems of downstream federated GraphQL queries. And query complexity. And unbounded queries. And extreme overfetching of data that all clients inevitably do. And...
Because people love chasing tech fads.
Here’s my workflow for creating an API with Postgraphile:
(That’s it)It’s trivial to query it with curl, I’d give an example but I’m afk rn.
I’ve been using GraphQL for about the same amount of time as in the article and it solved a bunch of problems for me.
It’s so easy to use, and saves so much time - once you spend the time to understand it.
The complexity of GraphQL in fact begins there, and also sort of explains a lot of why GraphQL is all but simple: Why am I using a query language instead of just passing an AST via JSON, a data format every general purpose language supports very well these days?
The answer to the above question, and most of GraphQLs other complexities: Some arbitrary design decision.
Another example: GraphQL could've easily been expressed as a REST API, even an Open API. From what I have seen, with the help of VC backing and FAANG endorsement, GraphQL mostly rose to replace JSON:API, which accomplishes pretty much all of the same goals in just JSON (and is RESTful).
One big issue of GraphQL is also that API clients tend to suck. That's not a problem for OpenAPIs.
And again, why is this the case? Some arbitrary design decision.
I feel like in general, someone creating a new DSL where it's not needed (and is obviously designed to look cool rather than actually be expressive), is a good sign they're just writing the software to stroke their ego rather than reach a meaningful end.
That's why in all the promo material for GraphQL you only see the query language, and not all of the actual setup required to send a request or even what an actual GraphQL HTTP request looks like. GraphQL, the framework, is not actually as simple and elegant as GraphQL the query language attempts to portray it as.
It's almost like someone came up with a query language for fun then came up with all the details of how a web server would utilize it afterwards.
Even today, GraphQL markets itself only as a query language (A query language for your API). When, as you have already mentioned, it is more than that.
That's why most developers know vaguely what GraphQL is ("Oh, that one language") but not how it actually works in practice. And when they actually encounter it, it feels almost like a betrayal, because it's nowhere near as simple, sleek or elegant as all the marketing they saw suggested.
At least, this was my experience when having to deal with a third party GraphQL API (funny enough, they migrated from REST, see ShipHero).
The reality is that GraphQL is a great tool for one job: building APIs that scale across thousands of engineers, billions of users, and many megawatts of machines. This is what we use GraphQL for at Meta.
To make it work well, it takes dedicated teams building infrastructure that makes the DevX great. It takes many years to build this out across various backends, clients, and internal tools. We have open sourced some of this infra — the GraphQL spec, Relay, GraphiQL, etc.
But there are many tools we built that we have not open sourced yet, largely because they’re tightly coupled to our internal ORMs, runtimes, error handling, authentication and security systems, and so on. I wish we open sourced more of our GraphQL stack, so more people could experience the awesome DevX we have internally.
At the same time, GraphQL is a tool. No tool can be used all the time for everything. Meta’s 3rd party APIs still use REST for this reason; some internal services use Thrift; etc.
It’s up to you to evaluate the tools available to build the way that makes sense for your business. Because some parts are available off the shelf, but others often need to be built in house, it is up to you to understand that cost and evaluate whether it is worth it for your use cases.
My hope is that as time goes on, more dev tools startups come in the fill the gap in tooling around client libraries, auth, security, and so on to make GraphQL a good choice at smaller scales, too. The DevX is that good when you get it right.
Just like the title of the article suggests, GraphQL is great, but ONLY in the right context.
- Good support for HTTP 1.1
- Provides typesafe contracts for queries and mutations
- Strong support for most common UI clients (JS/React Native/SwiftUI)
- Backend can be written in a language that isn't JavaScript/TypeScript
- Large developer community
Closest thing I've found is defining your schema using OpenAPI spec, and using tools to generate code from that source for the client and server, but this is a much worse DX than the process of defining GraphQL schemas.
If you're coding resolvers by hand, that is not fun. But for example the Lighthouse GraphQL layer for Laravel (it's a schema-first thing based on the Webonyx PHP GraphQL reference implementation) can do a lot of this for you using schema decorations.
https://lighthouse-php.com
It has where/filter/sort/pagination, automatic scope narrowing etc., and you have very little code (if any) beyond the graphql schema to set it up. It integrates brilliantly with the Eloquent query builder.
One of the best applications for PHP IMO; it is really enormously productive.
GraphQL is just the protocol. It is up to implementations to add support for it. We use Hot Chocolate GraphQL server with entity framework backend, and it has built-in support for all of those things.
Vast majority of the criticism of GraphQL comes from people who do not understand it. GraphQL does have a steep learning curve.
GraphQL, but more specifically GraphQL Federation solves an organisational problem. With Federation, teams can collaborate on building an API together with a Schema Registry and Composition Checks across all Subgraphs (Services), which is a unique enabler in the market.
We've got a lot of customers in the enterprise segment and it's growing rapidly to the point where I'd say it's becoming an enterprise standard.