BluePenguinB
Convex Community4mo ago
17 replies
BluePenguin

First-class offline migrations

I realise that Convex's focus on online migrations is good policy for apps that run at scale.

As an pre-PMF company we just want to rapidly prototype and having to do multi-step actions for a new non-nullable field (1. add optional field, 2. migrate, 3. remove optionality) really kills our speed.

This approach also kills typesafety. I provide an example below

We'd love to be able to do offline-migrations that still keep type-safety & schema validation.

Example:

* Write migration
* Deploy convex
* Transaction start
* [Convex]: disable schema validation
* [Convex]: execute migration (this would be a non-typesafe step)
* [Convex]: validate new schema
* [Failed]: fail transaction & revert
* [Success]: enable schema validation
* Transaction end
* [Convex]: if success: deploy everything else
* [Convex] server online

Why does the current approach kill type safety?


Between step 2 (run migration) and step 3 (remove optionality) there is a non-trivial amount of time, because both require separate deployments and a code change.

Therefore the optionality is still present AFTER the migration and BEFORE the new schema.

This means any typescript verification will NOT catch inserts that leave the new document's value unset. Therefore there is a possibility of breaking the ability to execute step 3 during that time.

This to me breaks one of the big values of Convex; end-to-end type safety.

It leaves me leaving optionality everywhere and running run-time checks (opposed to deploy-time-checks) which is inherintly a non-TS approach.

If you got this far thanks for reading.
Was this page helpful?