Data structures are at the center of Thin Backend applications.
Based on the Schema, Thin derives TypeScript bindings, APIs and Migrations.
Thin has a built-in GUI-based schema designer. The schema designer helps to quickly build the DDL statements for your database schema without remembering all the PostgreSQL syntax and data types.
But keep in mind: The schema designer is just a GUI tool to edit the underlying SQL statements. The schema designer parses the SQL statements, applies changes to the syntax tree, and then writes it back.
Rather work with your keyboard? You can always skip the GUI and go straight to the code editor. If you need to do something advanced which is not supported by the GUI, just manually do it with your code editor of choice.
Whenever you add or change a table in the Schema Designer, the changes will only be applied to the in-memory schema. The actual postgres database will only be touched when you run migrations.
You can think of this like in a git workflow: In git changes are only applied to the repository history when you do a
git commit. In Thin Backend this
git commit is running a database migration.
Quickly add columns to your new tables.
Null Safety: By default all your columns are marked as not null-able. Need to store nulls? Just hit the checkbox.
Foreign Key Conventions: Name your column like
projects_id and Thin Backend automatically sets up the required foreign key constraints.
Thin Backend uses Postgres Policies to make sure that users can only see what they're allowed to see.
Based on naming conventions Thin Backend will automatically generate the initial policies for you. You then only need to adjust the default policies based on your needs.
E.g. if you add a column called
user_id to your
tasks table, it will add a policy that allows users to read their own task records and only add tasks with their own user_id:
CREATE POLICY "Users can manage their tasks" ON tasks USING (user_id = ihp_user_id()) WITH CHECK (user_id = ihp_user_id()) ;
In Thin a database migration is a list of SQL statements that will patch the database from the old version to the new schema version. Similiar to how a git commit is a patch from the old code version to the new one.