Re:How and why GraphQL will influence the Sourcehut alpha
by kabes on Thursday June 11, 2020 @03:07AM
(#23485977)
"You have to calculate the burden of the query before you execute it so you don't end up crashing your database."
This sounds like disaster waiting to happen.
Re:How and why GraphQL will influence the Sourcehut alpha
by staticassertion on Thursday June 11, 2020 @12:07PM
(#23490291)
It's not nearly as complex as paging, which has a similar purpose of limiting single-query complexity.
Re:How and why GraphQL will influence the Sourcehut alpha
by tomnipotent on Thursday June 11, 2020 @03:07PM
(#23492275)
Anyone use MSSQL before it got ROW_NUMBER and window functions? Paging was a literal nightmare - if you wanted records 101-110, you had to fetch 1-110 and truncate the first 100 rows yourself (either in the DB via stored procedure or in your app code). I wish LIMIT/OFFSET was SQL ANSI standard.
You need to have data loader (batching) on the backend to avoid n+1 queries and some other similar stuff with cache to improve the performance.
You also have cache and batching on the frontend usually. Apollo client (most popular graphql client in js) uses a normalized caching strategy (overkill and a pain).
For rate/abuse limiting, graphql requires a completely different approach. It's either point based on the numbers of nodes or edges you request so you can calculate the burden of the query before you execute it or deep introspection to avoid crashing your database. Query white listing is another option.
There are few other pain points you need to implement when you scale up. So yeah defo not needed if it's only a small project.