effect-app / libs

The core libraries to build apps with Effect
44 stars 6 forks source link

Field level metadata for storage #91

Open patroza opened 1 week ago

patroza commented 1 week ago

One of the best things about Schema is how it is the central definition of all models throughout the system. By centralising all information for a model schema, property metadata, jsonschema metadata, and more, while deriving variations and views from them, there is a single source of truth and the distance between related information is very short, making it easy to get an overview quickly.

A great example is that you can access aTag.tag, aLiteral.literals, or aUnion.members, or aStruct.fields, instead of maintaining separate lists, possibly located at different ends of the application, making it harder to keep things in sync.

For Repositories we separately define the primary key and defaultValues/jitM from the Schema, I would like to explore if and how we could centralise this too, as they are in fact kind of properties of the Model, even though interpreted/executed by the Repositories/storage layer.

When type information is not required, one can simply use Schema annotations. But in case of type information required, we should either wrap PropertySignature or Schemas, similar to how effect model in sql does.

Suggested helpers (WIP names):

Some inspiration in Effect sql Model:

Not saying we should go that level, to expose more SQLesque stuff into our model though. We should remain abstract enough and not "infect".

Schema annotations: https://effect.website/docs/guides/schema/annotations which power all kinds of things like https://effect.website/docs/guides/schema/schema-to-x/json-schema