Re:GraphQL Is a Trap?
by ryanbrunner on Friday May 06, 2022 @04:42PM
(#31289433)
"Rigorous limits" for a sufficiently large database means "uses our hand-picked indexes effectively", which reduces down to "provides the same functionality as a REST API" since you need basically a whitelisted list of acceptable operations. At best you can reduce transfer time by limiting columns returned, which is something but not really worth the added complexity.
Re:GraphQL Is a Trap?
by lubesGordi on Friday May 06, 2022 @06:00PM
(#31289998)
I guess I've always assumed the graphQL would be a nice way of implementing a rest api, not something you'd expose to the customer directly.
Re:GraphQL Is a Trap?
by mumblemumble on Saturday May 07, 2022 @05:14PM
(#31298668)
My experience trying to maintain databases that are directly exposed to multiple development teams tells me that even exposing a fully generic querying API internally is risky.
Which, just for context - that's not me saying "graphQL is bad", it's me saying, "graphQL making it hard to do that is a feature, not a bug."
If it's not rigorously defined there are no limits, just what people can get away with.
With GraphQL you get the worst of both worlds that people can't write arbitrary queries but they can still trash the system. At least with undefined semantics people don't need to argue about whether or not they got the right answers.