Generator: use OpenAPI to generate watermelonDB

[TGTGamer]

So, this is possibly an edge case, but I feel like for me, it's worth the time to develop.

TLDR: Use the Open API (OAPI) schema to automatically generate database models and schemas with migrations in line with OAPI specifications. Connect to tools such as Axios or other fetch methods to provide API access from within the writer & reader functions.

Why

So we have a use case where we don't want to allow users to access our database directly (security 🥇), and therefore are defining OpenAPI endpoints for everything. The application must be authenticated, but other than that, almost all the properties which exist in the database are defined in the OpenAPI schema.

We would like to be able to push updates to our OpenAPI which are versioned correctly, with decrepit fields implemented and tags, which then generates a database based on the schema so we don't have to manually write these updates.

If we could also connect it to fetch based api tools, such as axios, we could then also define all the api calls on the model class, which can be populated with defaults such as headers when they are created.

This would save significant time over a project's livespan, allowing developers to focus on the important things like how those models are actually utilised in the application

How

I was thinking about the how, and I think it's fairly straightforward.

Tables: Tables should be user defined in a config. We can allow them to define either a path or tag to generate, which will then populate the rest of the fields from OAPI.

Column name: OAPI defines params which are available on each endpoint, we can simply pass these as their current name

Column type: OAPI already defines the types of params we would be processing, so we can simply create columns using those predefined specifications.

Migrations: Migrations are one of the more complex issues because migrations aren't fully defined in yet in this application, we would utilise decrepit and description to define how the migrations need to be actioned.

• When a new table or columns need to be defined we will need to figure out a way of reading back the previous generation (probably store it in a git commited json or something) which then allows us to correctly define the migrations.
• For deletions, we can use the decrepit field, and a description which defines on the initial line how the migration should be implemented (rename, delete)
• For optionality, we can get if the field is optional from OAPI and once again have to pass the previous state to allow us to define which migrations need to happen

When

At the moment, I am working on a project which would benefit, from this idea, and it's in the early stages, so I might work on an alpha version of this concept, but I would be interested in the community thinks about this

[JWDT]

I've done a similar but way more basic thing that converts all my SQLModel classes to Typescript and Watermelon schema files.

Haven't done anything with migrations yet as projects aren't close to being released (so databases are getting regularly re-built anyway), but since FastAPI generates OpenAPI spec anyway this could work just as well.

[matifriaz]

I think that's a great idea. Have you released the alpha version yet?

[TGTGamer]

Hi there. I actually moved away from watermelon due to other issues. Additionally not working for the company which was looking at this issue so haven't held onto the data.

Sorry to disappoint.