question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Support for IQueryable backend

See original GitHub issue

Is your feature request related to a problem? Please describe. My GraphQL backend database is an SQL database, and I’d like to consolidate queries as much as possible. Right now I can batch multiple queries into one using DataLoaders, but ideally I’d like to fetch as much of the graph as possible (ideally the whole thing) using single query with multiple join statements (essentially what graphql-net project does).

Describe the solution you’d like Hot chocolate resolves graph one leve at a time, which is an idea deeply rooted into ExecutionStrategyBase class, which is something core enough to the concept that it seems it cannot be easily replaced or tampered with. I think there’d have to be execution strategies which are different depending on the approach you want to take: fetch a level at a time or build IQueryable instances that’ll fetch the whole thing at once. In the latter approach, I’d say the resolvers instead of providing the objects wold have gradualy build up the IQueryables that then fetch the data which is in turn processed again by a 2nd batch of resolvers which do post-processing, as data fetched from DB might not correspond 1 to 1 with graphql query in some cases.

Describe alternatives you’ve considered The alternative of simply using graphql-net is not feisable for me because I’m on .NET Core, which that library does not support. The most viable alternative right now is to stick to data loader approach.

Additional context Add any other context or screenshots about the feature request here.

Issue Analytics

  • State:closed
  • Created 5 years ago
  • Reactions:4
  • Comments:14 (7 by maintainers)

github_iconTop GitHub Comments

1reaction
tkolocommented, May 12, 2019

Actually I’ll close this issue for now, if somebody ever needs an IQueryable backend I guess they can open another one.

1reaction
ChristianWeyercommented, May 12, 2019

Hi @michaelstaib - thanks for the update. This feature would be interesting, however, I do not really need it right now. Sorry 😉

Read more comments on GitHub >

github_iconTop Results From Across the Web

Support for IQueryable backend · Issue #553
My GraphQL backend database is an SQL database, and I'd like to consolidate queries as much as possible. Right now I can batch...
Read more >
Is it still necessary to support IQueryable for my ORM?
I was the noisy brat guy that created RepoDb ORM for .Net. I am now revisiting the solution to consider the requests to...
Read more >
How to handle backend Exceptions in IQueryable ...
A scenario with a HttpClient calling a ASP.NET Web API method, calling an EF repository. I am having trouble catching SQL exceptions. Client:...
Read more >
Avoid Proliferating DbContext or IQueryable in .NET Apps
IQueryable data is harder to reason about. It's difficult to know if a given instance of some data type coming from another service...
Read more >
IQueryable<T> Interface (System.Linq)
Provides functionality to evaluate queries against a specific data source wherein the type of the data is known.
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found