We still have a schema definition in TypeScript, without it things would have been pretty wild actually. But we're doing it in the app layer - in the framework. The schema management idea is that we're adding guardrails around all schema changes, so if you change the type of an existing field, rename fields, etc, we're automating the transition so the new code doesn't just run on the same old data without any knowledge of past structure.

Most of the users we talked to had issues when they made changes like this in the schema with app builders, in any database regardless, where the management layer doesn't exist.

▲

apsurd 5 hours ago | parent [-]

I've run into schema issues specifically with things like supabase: the huge benefit to supase is really fast and effortless prototyping. But after that actually maintaining your app becomes really hard and you pay the tax back over time.

In this regard, once past prototyping, i agree i've never had issues with LLMs running into schema problems, given they're doing a full feature, they're in line with how things need to change across the app.

LLMs do great at inspecting tables via Rails models and db adapters that can run sql commands to inspect all schema.

▲

artahian 5 hours ago | parent [-]

That makes sense, and we've been seeing the same. But in our case, instead of having the LLM inspect an external system, TypeScript is the source of truth for both the schema and everything else, it's all code-defined, so it automatically both catches type mismatch and also makes it instantly readable both to developers and agents.

▲

koakuma-chan 5 hours ago | parent | next [-]

I think this actually makes a lot of sense. How do you automate transitions? Do you generate code to map old data to the latest format, or do you actually migrate the data?

	▲	artahian 5 hours ago \| parent [-]
		A lot of this is still work in progress, but the key idea is that the framework and the cloud environment have to work together for this, because what you have in the current version of the code has to be compared with what the environment has before the deployment. We don't automatically generate migration code - there's a set of structured mapping / guardrails, so for example if you add a new field without marking it as optional, you should get a warning/error when deploying it on an environment with existing data that has old records without that field set. Modelence also has built-in support for user-defined migration scripts for more complex cases, but in these simpler cases we will be adding easy mappings with existing patterns, for example "set the field to X as the default value for all existing data". Our focus here is the guardrails rather than the migration itself - LLMs today (especially Opus) are smart enough to figure out how to do the migration, but the guardrails make sure they don't miss it under any circumstances.

▲

apsurd 5 hours ago | parent | prev [-]

good point, single type source is very appealing and LLMs are so good with TS because of those type interfaces.

only downside is forced js ecosystem x_X

	▲	artahian 4 hours ago \| parent [-]
		Agree, as for the JS/TS lock-in, we could have applied a similar approach with other languages too, but we intentionally chose to focus on one single stack to create a seamless end-to-end experience instead of providing a generic solution for multiple stacks, because a lot of the problems we're solving are different based on what stack you choose.