3 ms·
This seems like a "be careful what you wish for" situation. Sure, you could set up an algebra that allows you to handle arbitrary queries for zero extra progra
by mumblemumble 4y ago
This seems like a "be careful what you wish for" situation.
Sure, you could set up an algebra that allows you to handle arbitrary queries for zero extra programmer effort, just like a SQL database engine does. And then you could even expose it to users, and let them execute arbitrary queries.
And then, later, after you're done cleaning the molten slag off the server room floor, you could stop and reflect on whether that was really such a necessary thing to do.
- PaulHoule 4y agoIf you had a rigorously defined system you could put rigorous limits on it. 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.
- ryanbrunner 4y ago"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.
- lubesGordi 4y agoI 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.
- mumblemumble 4y agoMy 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."