[fhunt]

While Hasura is nice, it's too much blackbox, too much all-in, too much risk, we decided against it.

2021 is great because of TypeScript, types and decorators (just put here any other typed lang with decoraters if you do not like TS). If your db is your leading system for your schema, everything else is derived and "code-generated" with all the restrictions SQL has. Which is not great if you want to decorate and enhance. Yes, you could use interfaces but it's not the same, you can't decorate code-generated type definitions but your architecture wouldn't stay DRY either.

If you think TS' types as the leading schema you do not need a type checked db like Postgres anymore, anything which can store data works just fine you have all schema definitions at one place which is not the DB. Good examples enabling such an architecture are TypeORM and TypeGraphQL. However most stick to SQL and 'my schema must be in my DB, there is no other way to enforce a schema' (but there is!) you just need a good architecture (types and decorators!) and not another mainstream-from-the-shelf-solution.

[cies]

Interesting. My db and it's types have whole migration procedures to ensure all works on all environments, Hasura also does this.

How would that work with just-TS? The schema changes but the documents in my KV-store (I assume that what you mean by "no types on the storage") have not changed accordingly. How to prevent this obvious trouble?

[fhunt]

Depends on the schema changes. If you (1) change/remove existing keys from existing types, you need as well a migration which runs before the app starts. If you (2) add new keys to existing types or add new types you don't need migrations. That's the beauty of NoSql or in particular Mongo which most forget, you just write to the db and Mongo creates key, collections and dbs on the fly if not there yet. But again, only do this if you have validations before in place. Otherwise you end up will all these people complaining without having a full understanding of type safety and where to deal with it.

Case 1 should be always prepared well or better avoided if possible. It doesn't matter if you have sql or nosql, they're just more complex and with a big production database some longer downtime is to be expected if the changes/migrations affect large parts.