4 ms·
I have a simple question -- I've looked at GraphQL in the past and it seems extremely limited when you start wanting to do more complicated types of joins for p
by Exuma 5y ago
I have a simple question -- I've looked at GraphQL in the past and it seems extremely limited when you start wanting to do more complicated types of joins for performance, etc. This is such a fundamental thing to any webapp in my mind, and yet when I ask this previously people are often like "uhhh yeah...... use joinMonster I GUESS?"
Has GraphQL improved? I literally can't fathom using some kind of external plugin just to load data using more complex queries for performance reasons.
- replygirl 5y agoever considered db views instead of doing a bunch of joins at fetch time?
- Exuma 5y agoYes, but not every query should be a view (materialized or not) because the ORM doesnt support things like lateral join, cross join, etc.
- emteycz 5y agoWhy can't you just build a special GraphQL query with the SQL query you want? I mean having something like query { myCustomQuery(...params...) { id whatever } } backed by async function resolver(ctx) { const rows = await db.query(sql`SELECT yadda as id, badda as whatever FROM dabba JOIN dada ON ...`); return rows; }
- Exuma 5y agoWell if that is possible, that's great, but when I've asked similar questions before the answer is always to use some external library like joinmonster or whatever.
- emteycz 5y agoThis is easily possible with the low-level graphql NPM package which is the base of many frameworks. Most give you an option to get through the abstraction and do it.
- szundi 5y agoHow refreshing to see something else than foo and bar
- srcreigh 5y agoNothing about GraphQL causes a join monster.. that's just unbounded limits on the front end queries. You could validate against having too many layers of nesting in one query, validate pagination, provide abstract relationships for the many nesting and special case those joins, etc. It's basically a question of how to efficiently query data. There's always ways, but it might require some trimming of allowed graphql queries.
- Exuma 5y agoI was referring to this: https://join-monster.readthedocs.io/en/latest/ https://join-monster.readthedocs.io/en/latest/
- dthyresson 5y ago> You could validate against having too many layers of nesting in one query The GraphQL Server in RedwoodJS does query depth limiting out-of-the-box. You can configure it, but by default the depth is 11 -- because all the best things go to 11. [1] https://redwoodjs.com/docs/graphql#query-depth-limit https://redwoodjs.com/docs/graphql#query-depth-limit
- beaconstudios 5y agoGraphQL is designed around CRUD fetching patterns - so typically you would have a query per data type slice, and that query can be as complex as you like. In order to avoid N+1 queries, you should use dataloader: https://github.com/graphql/dataloader https://github.com/graphql/dataloader. You can also join additional data to reference in deeper resolvers, but that's an antipattern AFAIK.
- benatkin 5y agoThe latest release of dataloader happened more than 2 years ago.
- girvo 5y agoDoes it need more work? I'm genuinely asking, I've not used it
- deleted 5y ago[deleted]
- doctorbuttes 5y agoDataloader is a super simple idea + library; I doubt it needs any updating. Edit: great video on it by creator: https://youtu.be/OQTnXNCDywA https://youtu.be/OQTnXNCDywA
- benatkin 5y agoIt's a pretty reliable indicador of disuse.
- michaelghayes 5y agoFWIW, the Guild (the group behind a lot of the more popular GraphQL libraries) has recently take stewardship of this package, and it looks like there are already a few recent PRs merged into the repo. Lack of updates also isn't necessarily an indicator of disuse. It currently has close to 5 million weekly downlaods, roughly 1/5th of express which is probably the most popular library for building APIs in node.
- ncrmro 5y agoPostgraphile turns postgres schema into GraphQL schema, can do, filtering, aggregates, computed columns, filtering on computer columns etc
- manquer 5y agoIt really depends on how the resolvers are written, GraqhQL is just a interchange mechanism like RESTful APIs . You can do same things good or bad on both. Depending on the framework that use for your DB-to-GraphQL layer (like Hasura / join monster/ PostGraphile / subZero etc) there can be some there can be some limitations on what it can and cannot do, but that is not really a GraphQL problem. The GraphQL specific gotchas for me where - For most part component level queries works well, occasionally batching in higher component is important for performance, for example instead of executing a secondary query on each row of the table ( say fetching photos of user profiles from a different store) doing it one level up can speed things up. - Caching has to be solved very differently than RESTful APIs, GraphQL has everything in one endpoint as POST and you cannot leverage CDN's to cache the canonical resource URLs - Less verbosity or nested request-responses could be important for UX performance, using HATEOS style discoverability usually results in many APIs calls 2-3 levels or more deep, in RESTful systems that is not a major problem as you are caching API responses in nodes in dozen locations/CDN PoPs near the user but that is not possible in GraphQL, so you have to keep mind of verbosity, that can also impact how you store and index your database and how you configure and run replicas etc at scale. --- Anecdotally I have used Hasura as GraphQL frontend for an existing mature PostgreSQL db and APIs, (1 tb+, 1000's of concurrent users), and it scales fairly well even with 4-5 level nested joins or fetch ten of thousands of nested records. Hasura also does subscriptions reasonably well and they don't use triggers for implementing it. Some areas that needed a bit work around for me - recursive CTEs, cross-db joins, performance of very large counts ( postgres problem - using HLL or tuples from the planner if approximate values are fine.
- deleted 5y ago[deleted]