It does not-- we've been using graphql intensively with relationship-heavy graph data and join-monster seems handle this gracefully.

join-monster.readthedocs.io

Wow! Thank you, I have been looking for something like this. I use mostly NoSQL which typically doesn't do joins (unless it is a graph database) but this looks really usefully for when I do have a SQL database to work with.

If you use a graph database, something like the GraphQL compiler project might be useful: https://github.com/kensho-technologies/graphql-compiler

Primer on how to use it: https://blog.kensho.com/compiled-graphql-as-a-database-query...

I work at Kensho and we use it with queries that are 10+ levels of nesting with no problems.

Interesting approach for using GraphQL with a graph database. There is also an integration for Neo4j [1] that works similarly (it translates GraphQL to Cypher), however it also exposes Cypher in GraphQL through a @cypher directive, which maps complex graph traversals/aggregations to a single GraphQL field.

[1] https://www.npmjs.com/package/neo4j-graphql-cli

it's a great solution as long as your queries are no deeper than 2 levels

@tylerbainbridge and I work at Conduit (https://conduithq.com), where we are using GraphQL, join-monster, and PostgreSQL in production.

What you describe isn't a limitation at all-- some of our queries run 10 levels deep and work just fine. In fact, this method is so powerful that most of our queries start from the `user` object and just JOIN off of it.

agreed. If people understand what Join Monster does then they'd see it is still suboptimal in a world where we have Postgres and LATERAL :-D

Haven’t read enough into lateral joins myself, but if set to pg dialect, join-monster uses lateral joins for pagination: http://join-monster.readthedocs.io/en/stable/dialects/

I’m sure they’d welcome further feedback or pull requests...