Implement Dataloaders (N+1 issue) with middleware or follow docs example

[daniel-skale]

Hi all, I am trying to incorporate Dataloaders (https://docs.graphene-python.org/en/latest/execution/dataloader/) to our schemas to reduce load on our DB. However, I was wondering if anyone has had experience using either a middleware implementation vs. the ones outlined in the docs?

I also found that saleor uses a slightly different approach that is more similar to what was suggested by the docs. Just wondering if any1 has had experience using this feature in a bigger project.

[wodCZ]

I'll add my 2 cents: We had some success with relatively low effort with tfoxy/graphene-django-optimizer.
Dataloaders, while explicit, required a bit much of boilerplate.

[daniel-skale]

Hey again @wodCZ ! Seems like graphene-django-optimizer is used mainly for grabbing lists, I was wondering if for single item queries we would probably have to resort to Dataloaders then? Also how are you and your team enjoying graphene? I feel like this project isn't being updated as often as I had hoped and I felt that I am limited/slowed down by limitations of stuff that graphene lacks and am constantly debating whether to just switch to node instead...

[wodCZ]

@daniel-skale
graphene-django-optimizer: It's not mainly for grabbing lists, generally it attempts to avoid n+1 issue. You can use it to resolve single item queries too, although it's not clear from the documentation.
Basically you wrap the resolved value (list, or single item) using gql_optimizer.query, and the method processes the query's AST and applies your resolver hints like select_related, prefetch_related, only, etc..
I don't really understand the internals, but it's usually pretty good at optimizing the queries, even if they start with a single object. We have several deep queries like the following one, and with a bit of resolver hint fiddling we're down to 3 queries or so.

query User {
    currentUser {
        id
        friends {
            edges {
                node {
                    id
                    username
                    posts (last: 1) {
                        edges {
                            node {
                                id
                                title
                                text
                            }
                        }
                    }
                }
            }
        }
    }
}

Also how are you and your team enjoying graphene:

This has gotten a bit longer and off-topic, so let me hide in in a spoiler (click to expand)

Currently we're running on graphene-django v2 and optimizer 0.8.0 on 2 production projects, both running on single t3.small and we measured max throughput around 30 rps. Graphene v2 is some lazy piece.
You can find a performance comparison of some Python graphql libraries in this tweet.

I feel like this project isn't being updated as often

At my team we noticed the same - Graphene v2 is outdated and v3 is lacking maintainers to be released.

From the available python graphql libraries we evaluated that:

• graphene is not suitable to start a new large scale project
• Ariadne, from guys at Saleor, is schema-first, which we'd like to avoid (too much boilerplate). Also, Saleor isn't, and doesn't seem it will be using Ariadne (the guys who write the lib don't seem to be using it) - another minus point
• Strawberry - looks promising, but at the moment Strawberry is still in early development. Notable point - one of the last active maintainers of graphene is one of the (active) core authors of Strawberry. He said he's using it at work, but again, he's a core dev. We didn't want to bet on the strawberry horse either.
• tartiflette - another schema-first approach, didn't pay much attention to that, but at least it's stable and seems to be somewhat active

After evaluating all that, we decided to have a look at the node ecosystem, and after several days of researching and testing, we started a new project at Nest.js with Prisma. Can't say whether it was a good or terrible decision yet. I considered the performance, architecture (while similar to Django, in Nest it feels more natural) and most importantly type-safety to be good enough pitch points to give it a shot.

All that said, if Graphene v3 was released and managed to catch back some momentum, I'd probably stick with the Django/Graphene stack, because of the rapid prototyping capabilities. I would consider the same if Strawberry got a stable version.

Hope this helps :)