GraphQL: The enterprise honeymoon is over

I work on an open source server project that is deployed in many different contexts and with many different clients and front ends. GraphQL has allowed us to not feel bad about adding extra properties and object to the response, because if a particular client doesn’t want them, they don’t request them and don’t get them. It has allowed us to be much more flexible with adding features that only few people will use.

I tend to agree with the author. GraphQL has its use cases, but it is often times overused and simplicity is sacrificed for perceived elegance or efficiency that is often times not needed. "Pre-mature optimisation of root of all evil" comes to mind when GraphQL is picked for efficiency gains that may never become a problem in the first place.

Facebook invented GraphQL to solve a very specific problem back in 2012 for mobile devices. Having to make multiple queries to construct the data needed in FE in mobile clients is bandwidth constraining (back then over 3G networks) and harmful for battery life, so this technology solved this problem neatly. However, these days when server-to-server communication is needed over an API, none of the problems Facebook invented the protocol for are problems in the first place. If you really want maximum efficiency or speed you probably ought to ditch HTTP entirely and communicate over some lower level binary protocol.

REST is not perfect either, one thing I liked about SOAP was that it had a strong schema support and you got to name RPCs the way you liked, and didn't have to wrangle everything around the concept of a "resource" and CRUD operations, which often times becomes cumbersome to fit into the RESTful way of thinking if you need to support an RPC that "just does magic with multiple resources". These are the things I like about GraphQL, but on the other hand REST is just HTTP with some conventions, which you necessarily don't have to follow if things get in your way, and is generally simpler by design.

The only thing I wish with REST is having a stronger vendor support for Swagger/OpenAPI specs. One of the things my team supports is a concept of Managed APIs for our product: https://docs.adaptavist.com/src/latest/managed-apis and we support primarily RESTful APIs but also couple of GraphQL based ones and the issue we face is that REST API specs for many products are either missing, incomplete or simply outdated, so we have to fix them ourselves before we generate our Managed API clients, or write them by hand if the specs don't exist. It's becoming easier with AI these days, but one thing I personally regret when we transitioned from SOAP to REST as a community, is that the strong schema support became a secondary concern. We no longer could just throw API client generator at SOAP's WSDL and generate a client, we needed to start handcrafting the clients ourselves for REST, which is still an issue to this day, unless perfect specs exists, which in my experience is a rather rare occurrence.

For me it’s really about the component-level experience.

* Relatively fine-grained re-rendering out of the box because you don’t pass the entire query response down the tree. useFragment is akin to a redux selector

* Plays nicely with suspense and the defer fragment, deferring a component subtree is very intuitive

* mutation updaters defined inline rather than in centralised config. This ended up being more important than expected, but having lived the reality of global cache config with our existing urql setup at my current job, I’m convinced the Relay approach is better.

* Useful helpers for pagination, refetchable fragments, etc

* No massive up-front representation of the entire schema needed to make the cache work properly. Each query/fragment has its own codegenned file that contains all the information needed to write to the cache efficiently. But because they’re distributed across the codebase, it plays well with bundle size for individual screens.

* Guardrails against reuse of fragments thanks to the eslint plugin. Fragments are written to define the data contract for individual components or functions, so there’s no need to share them around. Our existing urql codebase has a lot of “god fragments” which are very incredibly painful to work with.

Recent versions of Apollo have some of these things, but only Relay has the full suite. It’s really about trying to get the exact data a component needs with as little performance overhead as possible. It’s not perfect — it has some quite esoteric advanced parts and the documentation still sucks, but I haven’t yet found anything better.

Did my only ever podcast appearance about it a few years ago. Haven’t watched it myself because yikes, but people say it was pretty good https://youtu.be/aX60SmygzhY?si=J8rQF6Pe5RGdX1r8

Contracts for data with OpenAPI or an RPC don't come with the overhead of making a resolver for infinite permutations while your apps probably need a few or perhaps one. Which is why REST and something for validation is enough for most and doesn't cost as much.

Cypher tries to solve problems closer to storage.

GraphQL was designed to add types and remote data fetching abstractions to a large existing PHP server side code base. Cypher is designed to work closer to storage, although there are many implementations that run cypher on top of anything ("table functions" in ladybug).

Neo4j's implementation of cypher didn't emphasize types. You had a relatively schemaless design that made it easy to get started. But Kuzu/Ladybug implementation of cypher is closer to DuckDB SQL.

They both have their places in computing as long as we have terminology that's clear and unambiguous.

Look at the number of comments in this story that refer to GraphQL as GQL (which is a ISO standard).