This blog post has made the rounds, and I agree.
These are the general qualms I have with GraphQL:
- It goes against the grain of the web: There’s only 1 server endpoint, usually talked to via POST, which always replies with HTTP 200, even when there’s errors. It’s just annoying not to be able to tell different GraphQL operations apart in the browser’s network tool during development. And the same issues make operations like monitoring, rate-limiting, and debugging more difficult.
- Most front ends use the bad but somehow popular Apollo library to communicate with the GraphQL server. Regular (REST) APIs don’t require any package 1.
- Providing a secure external API via GraphQL is difficult. And spinning up an alternative API in addition to the GraphQL server moots the whole point of using
Nowadays there’s other technical solutions to document and enforce an API contract.
My experience with GraphQL for the past 4 years has actually been working with the Hasura GraphQL server. That project solves some of the issues described in the blog post linked above. It can be used as a “poor man’s backend” system too. It’s also of the rare bread of rock-solid, well-documented tools. Kudos to that team! But of course Hasura comes with its own caveats. It gave me pause when Hasura’s community call used the tag line “Is GraphQL dead?” while hinting at auto-generated REST endpoints…
Footnotes
-
Unless you poor soul live in a team where the first action of someone was to
npm install axiosout of old habit. Dude,fetchhas been ready for years now… ↩