[bryanrasmussen]

>And both these projects had clear signs of "learning-on-the-go" with loads of bad practices

I think two projects having loads of bad practices is too small a dataset to really assume anything, you sort of need to see widespread "bad practices" in the tech to be able to determine that the bad practice is actually the norm practice and there is perhaps a flaw in the tech that encourages that norm.

[arp242]

You're not wrong, but at the same time I think it's a decent data point that getting it right is not straight-forward and that, practical speaking, you at the very least need to think very carefully before actually using it.

"The idea of it" is sometimes fine, but then there's also "the practicality of it", and sometimes that's a very different thing.

Remember the old microkernel vs. monolithic debate; everyone more or less agrees that in principle, a microkernel is better. But the practicality of it is a lot more complex, so monolithic kernels and hybrid ones are much more common. Microservices vs monolithic is essentially the same debate, and I've seen a lot of Microservices with very poor implementations and a lot of problems. That doesn't mean the idea is bad in itself, but if it's hard to execute well, then you do need to be very careful.

There's tons more examples of this. You also see this sort of thing in e.g. politics, where what's "more fair" vs. "what's actually achievable without introducing heaps of bureaucracy and overhead" are sometimes very different things.

In the case of GraphQL, I think it's pretty obvious that the general idea, as described from a high level, is a good one. But the practicalities of it are a lot less straight-forward, as this article explains reasonably well IMHO.

[bryanrasmussen]

I think one of the issues is actually that GraphQL has no specific implementation, it's not like you have an SQL database and that's it, so one thing is that when you are consuming a GraphQL api it is impractical for various implementation related reasons from the vendor.

With GraphQL you are doing a lot of extra work query wise than you do with REST, which is supposed to translate into various benefits. But each vendor has different implementation details that affects whether you actually receive those benefits.

This is different than REST, the benefits of REST are generally the same for every vendor because implementation details and API are extremely simple, what is different is the data structure you receive back.

In GraphQL both the data structure and the implementation details are different. GraphQL I think doesn't make sense if you have multiple data sources from different vendors, because of this increase in complexity and not being to trust how good their implementation actually is until you've gotten into it.