Call for maintainers

[lorensr]

Dear Join Monster users,

Andrew (@acarl005) doesn't have bandwidth for maintaining, so I'm helping him form a team to take over.

Join Monster has 2k stargazers, 2k/week npm downloads, and is the best library for automating JOINs in your GraphQL resolvers! If you're interested in helping out, please email me at loren@graphql.guide with:

• What type of thing(s) you're interested in:
  • Triage issues
  • Test & merge PRs
  • Documentation
  • Project ownership (Admin access to repo and npm, cut releases, oversee contributor team. Will require more bandwidth—either approval from your company to devote work time, or passion & consistent free time outside work 😄)
• Approximate hours per week you'd like to devote
• Github username
• Whether you've read and agree with the https://github.com/acarl005/join-monster/blob/master/CODE_OF_CONDUCT.md

[klarstrup]

did ya have any luck?

[lorensr]

Yeah, we have a few low-hours/week folks. Could use more 🤗 https://github.com/orgs/join-monster/teams/maintainers

[namnm]

@lorensr We have been using join-monster since 2019. Here are some obstacles and how we solved them while using this library:

• The pagination enforces us to follow graphql relay specification, we just dont want that and would like to have a simple ORDER BY .. LIMIT .. OFFSET .. query. We solve it by appending that extra query in the where condition, which resulted a valid final sql, and it executed as expected.
• The batch for hasMany or belongsToMany is great, but it will load every related rows, which is definitely something we dont need. And as the above hack, the batch wont work since it appends my where with another where (we can solve this by another hack but we want dont use batch anyway as the mentioned reason, thus irrelevant). To actually solve this we use sqlDeps and ignoreTable to invoke our custom resolver, in the custom resolver we return another jm call where we can also insert the above query for full featured order filter pagination. I notice this would result in 1+N queries on the server side, however this is acceptable for us since we need to do 1+N on client side otherwise. There are a few lines of patch needed to make the custom resolver works, which checks the jm context and modify the field config to execute the resolver when it is in the correct context.
• Join is great, but if there are a lot redundant data, batch loader would be better. We want to modify this to allow batch loader when necessary via config, but we havent done this yet.
• Due to the nature of graphql library, the config usually comes into too verbose, we did make some utilities to overcome, but it could be irrelevant here.

[nicoabie]

@lorensr are you looking for maintainers? this seems interesting for me to contribute as I have done related work here https://github.com/agiletiger/graphql-sequelize-query-loader

[lorensr]

We are, thank you! Adding you to the Slack