Hotchocolate: Support for IQueryable backend

[tkolo]

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.

[michaelstaib]

Hi,

actually you can resolve the full graph at once with a middleware.

Which version are you using right now?

[michaelstaib]

So,

basically our stitching layer branches of parts of a query end delegates it to a remote schema:
https://github.com/ChilliCream/hotchocolate/blob/master/src/Stitching/Stitching/Utilities/ExtractFieldQuerySyntaxRewriter.cs

For queryable this could even be easier. If you are willing to work with us on this one we could integrate support for IQueryable.

[tkolo]

I wasn't aware of a concept of middleware at this level. Once I get familiar with this I'll let you know. For now, thanks for the pointers!

[tkolo]

Also answering your earlier question, I was on 0.6.11, It seems it's not introduced there yet. Migrated to 0.7.0-preview.38 now.

[michaelstaib]

We will release the 0.7.0 at the end of this week.

In your case a QuerySyntaxWalker combined with a middleware should work.

https://github.com/ChilliCream/hotchocolate/blob/master/src/Core/Language/Visitors/QuerySyntaxWalker.cs

https://hotchocolate.io/docs/next/middleware

[tkolo]

Thanks for the update, I've found that class already, though it's good to have a confirmation that I'm heading in the right direction.
I'll try to implement PoC of this, are you interested in this code? It'll probably have an explicit dependency on EF as I need Include() extension which is part of EntityFrameworkQueryableExtensions, so I guess that's a show stopper for including it in this project directly.

[michaelstaib]

Sure, once you have something we can have a look at how we can create an abstract solution for that.

Also, the SyntaxWalker has a T for a context so that you are able to collect data etc. Moreover, the SyntaxWalker will crawl the document graph not the execution graph, this means it will not follow the way that the execution engine would walk the graph since the walker does not resolve the FragmentSpread... In order to solve this with a circuit-breaker you can use the example of the rewriter or look at the MaxDepthVisitor....

Opt out of the default FragmentDefinitionVisitation
protected override bool VisitFragmentDefinitions => false;

... and overwrite VisitFragmentSpread.

Look at the MaxDepthVisitor for more help

https://github.com/ChilliCream/hotchocolate/blob/65aeef9bafea8903b4268ef0eb541b0dd7766b19/src/Core/Core/Validation/MaxDepthVisitor.cs

We will standardize this with version 0.8.0 but for now you have to do that.

Hope that helps

[michaelstaib]

As a side note, we have a slack group:

https://join.slack.com/t/hotchocolategraphql/shared_invite/enQtNTA4NjA0ODYwOTQ0LTBkZjNjZWIzMmNlZjQ5MDQyNDNjMmY3NzYzZjgyYTVmZDU2YjVmNDlhNjNlNTk2ZWRiYzIxMTkwYzA4ODA5Yzg

[ChristianWeyer]

@tkolo DId you ever get to finish your PoC? ;-)
Thanks!

[michaelstaib]

@ChristianWeyer we did not hear anything back from him. But we did a lot of work in that area and to implement this would now be significantly simpler since we now have the CollectFields method on the middleware context. This effectively removes the need to implement the visitor. Basically CollectFields resolves the fields for a given SelectionSet.

With version 9.1 we will bring Prisma like filter objects for IQueryable if you want to help implement this issue we would definitely help. At the moment we are more focused on performance and server features like @defer, streaming, batching and the prisma like filters.

If nobody picks this issue up we will do so with version 10. But as I said, if you are interested we would definitely help ti bring this to life.

[ChristianWeyer]

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

[tkolo]

No, I didn't finish my PoC. I wrote a visitor for most simple cases and talked it over with the rest of my team, only to conclude that this approach is too complicated for what we intend

[tkolo]

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

[michaelstaib]

@tkolo thanks for your feedback