Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Alternatives for "nestjs-query" #1571

Open
eugeny-dementev opened this issue Jun 15, 2023 · 8 comments
Open

Alternatives for "nestjs-query" #1571

eugeny-dementev opened this issue Jun 15, 2023 · 8 comments
Labels
enhancement New feature or request

Comments

@eugeny-dementev
Copy link

Since that library could be considered dead, what might be the replacement/alternative for it? Why it became obsolete, is there a better tool appeared/made by someone?

@eugeny-dementev eugeny-dementev added the enhancement New feature or request label Jun 15, 2023
@smolinari
Copy link
Collaborator

@eugeny-dementev - This is the fork that is being pretty well maintained now.

https://github.com/TriPSs/nestjs-query

Scott

@manlyman29
Copy link

My previous encounter (4-5 months ago) with that particular fork was less reliable compared to this one. I switched back to the doug-martin library for our codebase. It might be worth considering if someone's project lacks the necessary timeframe for contributions.

@smolinari
Copy link
Collaborator

In what ways less reliable? @TriPSs is keeping the library up-to-date and also even adding features. I've helped too where I can.

Scott

@manlyman29
Copy link

@smolinari
I can't recall the exact problem I encountered (I think it related to one of the decorator hooks being skipped), but I remember vividly that, at that time, the relations were not joined to execute a single database query. Instead, in most instances, a separate query was made for each relation.

@TriPSs
Copy link

TriPSs commented Jun 16, 2023

@ridyio good to know that for simple relations we now have the enableLookAhead option that will do it in one query, for other relations (one -> many) it's usually faster to do it in separate queries.

@smolinari
Copy link
Collaborator

it's usually faster to do it in separate queries

Or, if it is dealing with the n+1 problem, set up data loaders.

Scott

@manlyman29
Copy link

Thanks @TriPSs @smolinari. Glad to see that your fork is actively maintained. I'll surely try it out again.

@TechnotronicOz
Copy link

@doug-martin we should open up the maintainer group to keep this project alive

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

5 participants