91–100 of 241 posts
i wrote this a few weeks ago: https://gist.github.com/andrewarrow/c75c7a3fedda9abb8fd1af14... 400 lines of QL vs one rest DELETE / endpoint
How do GraphQL based systems solve the problem of underlying database thrashing, hot shards, ballooning inner joins, and other standard database issues? What prevents a client from writing some adversarial-level cursed query that causes massive internal state buildup? I’m not a database neckbeard but I’ve always been confused how GraphQL doesn’t require throwing all systems knowledge about databases out the window
Most servers implement a heuristic for "query cost/complexity" with a configurable max. At the time the query is parsed, its cost is determined based on the heuristic and if it is over the max, the query is rejected.
If you are using something which requires you to write the GraphQL schema manually and then adapt both the server and the client... it's a completely different experience and not that pleasant at all.
But the other graph query language "Cypher" always seemed a lot more intuitive to me.
Are they really trying to solve such different problems? Cypher seems much more flexible.
The article pretty much sums up why I've been a bigger fan of OData than GraphQL, especially in the business cases. OData will still let you get all those same wins that GraphQL does but without a sql-ish query syntax, and sticking to the REST roots that the web works better with. Also helps that lots of Microsoft services work out of the box with OData.
I'm probably about as qualified to talk about GraphQL as anyone on the internet: I started using it in late 2016, back when Apollo was just an alternate client-side state/store library. The internet at large seems to have a fundamental misunderstanding about what GraphQL is/is not. Put simply: GQL is an RPC spec that is essentially implemented as a Dict/Key-Value Map on the server, of the form: "Action(Args) -> Resul…
As someone who’s used GraphQL since mid-2015, if you haven’t used GraphQL with Relay you probably haven’t experienced GraphQL in a way that truly exploits its strengths. I say probably because in the last ~year Apollo shipped functionality (fragment masking) that brings it closer. I stand by my oft-repeated statement that I don’t use Relay because I need a React GraphQL client, I use GraphQL because I really want to…
What about relay is so compelling for you? I'm not disagreeing, just genuinely curious since I've never really used it.
Earlier quoted context omitted.
Most servers implement a heuristic for "query cost/complexity" with a configurable max. At the time the query is parsed, its cost is determined based on the heuristic and if it is over the max, the query is rejected.
Which would be fine for internal facing, but it doesn’t sound like it would be enough in an adversarial context?
An adversary is going to utilize more than a single query. It mostly protects against well intentioned folks.
Other forms of protection such as rate limiting are needed for threat models that involve an adversary.
The same problems exist with REST but there it is easier as you can know query complexity ahead of time at end points. GraphQL has to have something to account for the unknown query complexity, thus the additional heuristics.
We have a BFF and were considering for a while to go with GQL but eventually scrapped the idea: it seemed like a lot of work on the BE side. But, we are quite constraint on resources, so now even the BFF seems to consume more and more BE development time. Now we are considering letting the FE use some sort of bridge to the BE's db layer in order to directly CRUD what it needs and therefore skip the BFF API. That db l…