Having worked with SQL for many years now, I truly disliked using graphql when I used it. Most of the time all I need is just a csv-like structure of the data I'm working with and I had a very difficult time with just getting something like that. Joining tables tended to be difficult where the pivot points between relationships was rather semantically unbounded, so it was difficult for me to create a reasonably rigid mental model of the data I was working with. That was especially noticeable in some of the API documentation I worked with -- where a simple REST-like API just gives a simple, usually flat, json... graphql api responses were deeply nested and often in implementation-dependent ways[1] of thousands of lines. Which has IME made explorability practically impossible.
GraphQL implementations have consistently felt like a hobby project where implementing it in an API becomes a thing to put on a resume rather than making a functionally useful API.
GraphQL implementations have consistently felt like a hobby project where implementing it in an API becomes a thing to put on a resume rather than making a functionally useful API.
[1] https://graphql-docs-v2.opencollective.com/queries/account (navigate to the variables tab for a real mindfuck)