I was wrong about GraphQL - WunderGraph

I thought this was really smart. Having a JSON Schema for every operation would allow us to easily generate clients, forms, and documentation. However, as time went on, I realized that this approach is not as practical as I initially thought. Most companies had adopted existing GraphQL tools and libraries, which rely on the GraphQL schema. Adding this additional JSON-RPC layer introduces complexity and unnecessary overhead. … ## Generated GraphQL APIs: Tight Coupling as a Service I said the following on generating GraphQL APIs in 2020: > - works well for small projects and prototyping > - lacks capabilities to design > - violates information hiding > - forces business logic onto API consumers > - doesn't abstract away storage > - is hard to evolve because of tight coupling … ## GraphQL's @defer and @stream Directives are overkill In February 2023, I served a sizzling side of spice: > I argued that the `@defer` and `@stream` directives are overkill. My point was that we could instead use a Backend For Frontend layer to achieve the same results with less complexity. This is, once again, a topic where I previously was in favor of a JSON-RPC layer in front of GraphQL. ... … From discussions with our customers, it's clear that latency of Subgraph responses can vary significantly depending on the underlying services. For many use cases, every millisecond counts in the battle to provide the best possible user experience. Providers of e-commerce platforms, for example, can measure the impact of a 100ms delay in the response time in terms of lost revenue. With the help of the `@defer` and `@stream` directives, it's possible to optimize critical rendering paths in a way that shows the most important data first while the rest of the data is fetched in the background.