3 ms·
That backend engineer wrote a single SQL query that joined some tables, ensured indices were used, and always executed in <1ms. In graphql land you'd be doing
by RVuRnvbM2e 2y ago
That backend engineer wrote a single SQL query that joined some tables, ensured indices were used, and always executed in <1ms.
In graphql land you'd be doing multiple SQL queries, "joining" in the API layer, and spending 50ms per API call.
- hansonkd 2y agoWhat? GraphQL is purpose built to solve that in 1 Query. Not doing it in 1 query is on you not the protocol. In practice with REST the frontend engineer didn't want to wait and tried to use the existing REST endpoints, did N+1 API HTTPS calls and then joined them client side in javascript.
- fiddlerwoaroof 2y agoA lot of graphql implementation end up moving the n+1 problem to the query resolver.
- hansonkd 2y agoEvery GQL implementation I have seen explicitly has a way to avoid n+1 queries.
- RVuRnvbM2e 2y ago> What? GraphQL is purpose built to solve that in 1 Query. Not doing it in 1 query is on you not the protocol. 1 graphql query maybe. But that translated to a dozen SQL queries. > In practice with REST the frontend engineer didn't want to wait and tried to use the existing REST endpoints, did N+1 API HTTPS calls and then joined them client side in javascript. The point you're missing is that for 1 graphql query the API did N+1 SQL queries, and then also joined them in JavaScript. In the REST case the front end can switch to the efficient custom endpoint when it is implemented. In the graphql case it will never get any faster because the API has to stay generic.
- chuckadams 2y agoThe entire point of graphql servers is that they're basically ORMs (or use an underlying ORM) that turn complex nesting into a single query's worth of joins. It won't beat hand-crafted sql from an expert, but if that's your preferred approach, debates on the relative merits of different query frameworks are all academic to you anyway.
- RVuRnvbM2e 2y agoI've never seen this kind of graphql server implementation that can automatically boil down a complex nested query to sensible SQL. It sounds like the best of both worlds. Do you have links?
- hansonkd 2y agoTypically libraries use a Dataloader + ORM to implement this which gets you pretty far, outside of that some libs like Strawberry with automatically optimize your queries for you if you return Django ORM Querysets. Any query you were going to build and serve with Rest can be made with these two methods or even a raw dataloader and manual SQL string.
- discreteevent 2y agoThe inventors of GraphQL did not intend it to be mapped directly to a database. "That would be one way to implement the system in a DB-centric way. However we believe that intermediate application code is pretty critical to any GraphQL implementation." [1] "GraphQL is a client-server dance that needs server-side capabilities, not just CRUD semantics." [2] [1] https://news.ycombinator.com/item?id=9879870 https://news.ycombinator.com/item?id=9879870 [2] https://news.ycombinator.com/item?id=14351800 https://news.ycombinator.com/item?id=14351800
- hansonkd 2y agoThe Language Libs like Strawberry implement what he is describing by intermediate application code. It doesn't map directly to a database. GQL implementations don't map to the database but to application code.