Question re: N+1 and Authorization about dapper.graphql HOT 4 CLOSED

Thanks mate, will close.

from dapper.graphql.

Yep, it avoids the n+1 problem by growing query results horizontally rather than vertically. There's a point where this payoff starts to fade, but for most use cases you'll see a big performance increase.

I haven't used graphql-net's authorization toolset, but based on what I'm seeing browsing through their code, it shouldn't interfere with this library. Essentially, you build _QueryBuilder_s that are used by a single QueryBuilder that's rooted at the top of your schema. Each type resolves the same way it always has, this library just gets really critical about what information it retrieves on each object (preferably getting all data in one or two queries) before resolving.

from dapper.graphql.

I see what you mean, I did even more looking into it yesterday and my understanding is that if you do the following:

Field<ListGraphType<EmailType>>(
    "emails",
    description: "A list of email addresses for the person.",
    resolve: context => context.Source.Emails
);

you're resolver function is just grabbing the value off the already constructed/populated entity, which you're saying is populated by executing the root-level query builder's generated SQL and the subsequent entity mapper.

Does that sound right? If so, then I guess the Authorization library should still play nice as it will intercept the resolver function call (e.g. context => context.Source.Emails), apply the Authorization logic and approve/deny that field resolution.

Thanks, I think this is exactly what I need. GraphQL is great in principle, but without a really sensible layer to map the query to the data storage system easily, effectively and optimally it's very easy to run into trouble I can imagine.

from dapper.graphql.

@benmccallum Yes, that sounds right.

from dapper.graphql.