My biggest problem is that it seems like nobody understands the data or where the data is coming from. You can have the same variable names and mostly even the same values under different levels of the graph. Now someone has to figure out what system is feeding that info to GraphQl to figure out which level we should use. I don't see this as a real GraphQl problem, but more so a problem with the process discouraging detailed knowledge and documentation.
You can write shit in any framework or language though. That's why I always found Typescript such a boon; it provides a way to box people in to use code/framework how it was designed to be used.
It's definitely possible to write shit in anything. It just seems that writing something more structured, like SQL stored procs and a REST endpoint, means someone had to actually think about what data is coming back, it's structure, and how it's being used and the dev generally had better insight as to where the data was coming from and what values to expect.
There's a lot about graphql that is really cool. It just seems like the way my company uses it is to cut corners.
The same structure thinking etc can and should be done for GQL as well. But same same, once you have project handoff some other team can pick up your nice rest api and not follow existing conventions at all. I've seen far too many rest apis that will do all these variations across the one API: delete /user/comment, post /user/comment?action=delete, post /deleteUserComment, etc.
I'd agree that GQL is definitely one of those "gets used because it was the cool thing at the time" technologies but I still think it has a place in our toolboxes, it's definitely not the right solution for every problem.
