[juliennakache]

Quick plug: we've made good progress on solving this very problem for the SQLAlchemy ORM in Python. Our approach is a bit like Join-Monster but more flexible because:

  - we introspect your SQLAlchemy models and generate Dataloader-based resolvers that emit small independent SQL queries. This way this optimization composes naturally with other GraphQL types in your schema.
  - we are thin wrapper on top of Graphene, the main GraphQL Python library. It makes it very easy to extend your type if needed. We also added ways to rename and modify the type of a column / field.
  - for the SQL query generation we currently lean on SQLAlchemy to do the heavy lifting. It can emit efficient in IN() JOIN queries for us.

So far, it's been working quite nicely for us. We were able to generate decently performant schemas with very boilerplate on top of our existing SQLAlchemy models. And each time we've run into a case that the library did not optimize well for us, we were able to easily override its behavior by writing our SQLAlchemy queries.

There is still room for performance improvements but I'm confident we'll get there eventually (though I expect the optimizations to only work for DBs that support LATERAL JOINs). My main focus at the moment is to come up with an API that it possible to create performant types that aggregate multiple tables.

Links - https://github.com/graphql-python/graphene-sqlalchemy - https://github.com/graphql-python/graphene-sqlalchemy/pull/2...

EDIT: formatting

[chrstphrhrt]

I'm working on a project that depends on Graphene and Django (not my choice). Any ideas off hand about doing the same thing there? IIRC Django can also use SQLAlchemy but it didn't used to be very nice back in the day.

[juliennakache]

I haven't looked into the Django ORM recently but last time I checked I think it would have been a lot more challenging to implement something similar. SQLAlchemy is a lot more flexible, very well designed and actively maintained. My recommendation would be to try using SQLAlchemy with Django. It should work without any problems but you might lose the ability to use some of the Django plugins that assume the Django ORM.

[ris]

> IIRC Django can also use SQLAlchemy

It's possible to use sqlalchemy with django, but you're basically on your own (don't expect to be able to use django-admin and other pluggable apps etc.)

> it didn't used to be very nice back in the day

Having used both django and sqlalchemy ORMs very heavily, I've got to say that django does what it does extremely well and intuitively. For what the vast majority of webapps need to do, the "obvious" way of constructing the query causes django to do more or less the right thing. sqlalchemy on the other hand I love for other reasons, but am frequently annoyed at how much faffing is required to do the simple things in a concise way.

[true_religion]

One thing you can do is use SQL alchemy, by duplicating code so you will have Django code to handle things you want to do in Django.... typically anything that touches the admin or model forms, but use SQL Alchemy for everything else.

[ris]

Yyyyeah, but you do end up duplicating potentially quite a lot of code, especially if you're following the (IMHO nice) "fat models" approach.

I think a few people have thrown around the idea of creating a frontend to sqlalchemy to allow it to understand django model definitions and QuerySet semantics but I don't think anything's come of it.