Eight Years of GraphQL

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.

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.

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.

Disclaimer, I'm one of the authors of an open source project to implement GraphQL Federation (https://github.com/wundergraph/cosmo).

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.

I can say with 100% confidence that GraphQL via Postgraphile & TypeScript is a stellar tech stack for web applications beyond "hello world".

If you are building on Postgraphile and raising from angels, dm me.

GrahpQL was something that came up heavily in Front-End job ads and maybe even mentioned during my experience interviewing around 2017-2020 I was once even turned down for not having enough "GraphQL Experience" - Whatever that was. This was during a particularly painful 6 month rut for me - job search wise. It's absolutely infuriating that the tide has now changed. GraphQL doesn't matter. Did it ever? What was the point?

I think that instead of addressing and correcting the original post the author validated and confirmed everything that was said in that original post.

GraphQL is painful. I am thinking some SQL but with more access control would be better.

So if most of the issues with GraphQL are the same as with the other approach, what is the point of GraphQL that justifies all the complexity?