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

Operator support via Arguments #38

Open
narbit opened this issue Mar 14, 2019 · 0 comments
Open

Operator support via Arguments #38

narbit opened this issue Mar 14, 2019 · 0 comments

Comments

@narbit
Copy link
Collaborator

narbit commented Mar 14, 2019

I know this topic is not popular with GraphQL community for a set of valid reasons. Nevertheless, there is definitely a demand for this functionality for applications that are DB driven. If we don't have a semi-built-in way of dealing with operators, every person writing resolvers that eventually translate into SQL statements will have to roll their own. Should this be a part of this library similar to EF-backed one?

I go back and forth on the whole idea. There is definitely performance implications around querying DB in an uncontrolled way with potentially multiple nested comparison statements. But I struggle to find an alternative for the advanced filtering that would be both, safe and performant.

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

No branches or pull requests

1 participant