GraphQL: The enterprise honeymoon is over

It allows you to separate your GraphQL in multiple "sub-graphs", and forward them to different microservices and facilitates separation of concern at backend level, while putting them back as one unified place for the frontend, giving it the best of both world in theory.

Yet unfortunately, both stitching and federation is rarely in practice due to the people's lack of fundamental abilities to comprehend and manage complexity, and that the web development is so fast, that one product is put out for one another year by year, and the old code is basically thrown away and remain unmaintained, they eventually "siloified"/solidified *2, and therefore it is natural for a simple solution like REST and OpenAPI/Swagger beats the complicated GraphQL, becaues the tech market right now just want to make the product quick and dirty, get the money, then let it go, rinse and repeat. Last 30 years of VC is basically that.

So let me tell you, this is the real reason GraphQL lost: GraphQL is the good money that was driven out, because the market just need the money, regardless of whether it is good, bad or ugly.

Speaking asides, I enjoy GraphQL so much in C#: https://chillicream.com/docs/hotchocolate/v15/defining-a-sch..., they even have integrations with EF Core which is mind-boggling: https://chillicream.com/docs/hotchocolate/v15/integrations/e...

It is so natural, and I've tried to make it run in the new single file C#, plus the dependency injection and NativeAOT...I think I made the single-file code in their discussion tab, but I couldn't find it.

Another good honorable mention would be this: https://opensource.expediagroup.com/graphql-kotlin/docs/sche..., I used it before in place with Koin and Exposed, but I eventually went back to Spring Boot and Hibernate because I needed the integrations despited I loved to have innovations.

*1: For example, why force everyone to use HTTP/2 and thus enfoced TLS by convention? This makes gRPC development quite hard that you will need to have self-signed key and certificates just for starting the server, and that is already a lot of barrier for most developers. And the protobuf, being a compact and concise binary protocol, is basically unreadable without the schema/reflection/introspection, and GraphQL still returns a JSON by default and you can choose to return MessagePack/CBOR based on what the HTTP request header asked for. Yes, grpc-web does return JSON and can be configured to run on H2C, but it is more like an afterthought and not designed for frontend developers

*2: Maybe the better word would be enshittified, but enshittification is a dynamic process to the bottom, while what I mean is more like rotten to death like a zombie, so is it too overboard?

And you presume that the code hasn't been read or understood by a human. AI doesn't click merge on a PR, so it's highly likely that the code has been read by a human.

1. The main argument to introduce has always been the appropriate data fetching for the clients where clients can describe exactly whats required

2. Ability to define schema is touted as an advantage, managing the schema becomes a nightmare.( Btw the schema already exits at the persistence layer if that was required, schema changes and schema migration are already challenging, you just happen to replicate the challenge in one additional layer with graphQL)

3. You go big and you get into graphQL servers calling into other graphQL servers and thats when things become really interesting. People do not realize/remember/care the source of the data, you have name collisions, you get into namespaces

4. You started on the pretext of optimizing the query and now you have this layer that your client works with, the natural flow is to implement mutations with GraphQL.

5. Things are downhill from this point, with distributed services you had already lost on transactionality, graphQL mutations just add to it. You get into circular references cause underlying services are just calling other services via graphQL to get the data you asked for with graphQL query

6. The worst, you do not want to have too many small schema objects so now you have this one big schema that gets you everything from multiple REST API end points and clients are back to where they started from. Pick what you need to display on the screen.

7. Open up the network tab of any *enterprise application which uses graphQL and it would be easy to see how much non-usable data is fetched via graphQL for displaying simplistic pages

There is nothing wrong about graphQL, pretty much applies to all the tools. Comes down to how you use it, how good you are at understanding the trade-offs. Treating anything like a silver bullet is going to lead in the same direction. Pretty much all engineers who operated at the application scale is aware of it, unfortunately they just stay quiet

GraphQL, in combination with GraphQL has become the new standard for orchestrating Microservices APIs and the development of AI and LLMs gives it even another push as MCP is just another BFF and that's the sweet spot of GraphQL.

Side note, I'm not even defending GraphQL here, it's just about facts if we're looking at who's using and adopting GraphQL. If you look around, from Meta to Airbnb, Uber, Reddit or Booking.com, Atlassian or Monday, GitHub or Gitlab, all these services use GraphQL successfully and these days, banks are adopting it to modernize API access to their Mainframe, SOAP and proprietary RPC APIs.

How do I know you might say? I'm working with WunderGraph (https://wundergraph.com/), one of the most innovative vendors in the market and we're talking to enterprise every day. We've just came home from API days Paris and besides AI and LLMs, everyone in the enterprise is talking about API design, governance and collaboration, which is where GraphQL Federation is very strong and the ecosystem is very mature.

Posts like this are super harmful for the API ecosystem because they come from inexperience and lack of knowledge.

GraphQL can solve over fetching but that's not the reason why enterprises adopt it. GraphQL Federation solves a people problem, not a technical one. It helps orgs scale and govern APIs across a large number of teams and services.

Just recently there was a post here on HN about the problems with dependencies between Microservices, a problem that GraphQL Federation solves very elegantly with the @requires directive.

One thing I've learned over the years is that people who complain about GraphQL are typically not working in the enterprise, and those who use the query language successfully don't usually post on social media about it. It's a tool in the API tool belt besides others like Open API and Kafka. Just go to an API conference and ask what people use.