to use an ORM? #222
Description
Thinking longer term:
It's likely that we will need a reflection in the graphql schema to a database.... There are options out there such as https://github.com/graphql-python/graphene-sqlalchemy however:
- the ORM does not support async DB operations
- the ORM drives the graphql schema (uses graphene https://graphene-python.org/)
When last rewriting -api (years ago now :S ) graphene was lagging quite a way behind graphql-core-next and so -api was written without the use of graphene. Today graphene uses graphql-core-next and offers some nice convenience functions and a clear way to build graphql queries from an ORM.
Things to think about:
- Do we want to drive the graphql query generation using an ORM (as per graphene-sqlalchemy) or do we want to drive the ORM generation from the graphql schema? Personally I prefer the latter option (which goes against convention) as it means that if I can generate a graphql schema for something like mavlink we get the database models for free. Additionally, we can also choose not to have an ORM for some of the qraphql schema. If we drive the schema with the ORM we commit to needing a database entry for everything. This would make sense for 99% of CRUD web applications, but I don't think it makes sense for -api.
- Something like tortoise-orm (https://github.com/tortoise/tortoise-orm) can be used to resolve the async DB operations issue noted above, but there is no out of the box support for graphql
- I don't think it will be too hard to make a graphql schema -> tortoise-orm mapper if we do indeed go this way
- Perhaps I need to rethink how I am representing the graphql schema in -api?
- Will the adoption of something like graphene make on boarding developers simpler in the future when they want to write their own -api modules? Yes... but what are the technical trade offs?
Lots of questions and not a lot of answers at this stage...