| > It's not possible to build GQL query footguns. GQL literally allows unbounded queries. All the "tooling" around like "field complexity", "data loaders" and other hacks are literally that: hacks and workarounds, and they are not even consistently, evenly or even efficiently implemented among the various GQL libraries and frameworks. > it automatically comes with documentation for your API Unless it's specified in code, and to create actual documentation you have to run a server, connect to it with a tool, and dump it (can't remember which lib did that, was it in Java or in Go). > you think that using GQL automatically comes with the infrastructure I described. This: GQL doesn't come with infra. And for every thing that REST aready has and for every issue that GQL has, and REST doesn't, you need to add more and more infrastructure and "rich ecosystem": - Caching is literally built-in in HTTP. GraphQL's default method is POST, so to "solve" caching frameworks like Apollo have to act as middlemen unpacking every incoming request and every outgoing response looking for certain fields to figure out what to cache. Of course, this isn't available in other libs and framewroks - Unbounded queries are literally not an issue in REST (unless you build something weird). In GraphQL you need to "specify field complexity" if you framework allows that - Your REST endpoints know what exactly is requested, and can have specific hyperoptimised queries for that specific thing. GraphQL is ad-hoc by nature, any query is potentially n+1, so you have the workarounds with dataloaders which by definition cannot be optimised unless your specific framewrok gives additional insights into what's being requested. Literally everything around GraphQL is "nothing works well, and if you're lucky, a particular graphql implementation for your programming language will have some solutions for some of the problems". How do I know? I built a service prototype for an internal tool in 5 different languages with 6 different libs: - Typescript, Apollo - Java, graphql-java - C#, graphql-dotnet - go, glgen and graphql-gp - Elixir, absinthe GraphQL sucks ass for everyting and everybody except client developers who couldn't care less how it looks on the backend |
2) Try Hasura (or similar).
Sure, if your goal is 'I want to hand write hyper-optimized queries for every imaginable use-case' then graphql sucks. That's not what it's designed to do.
If your goal is to fast front-end development, reasonable efficient network usage, and combining different services together it's great. Tools like Hasura go an extra mile and offload a lot of work from the BE team.