Schema Designer

Data structures are at the center of Thin Backend applications.

At the center of a Thin application are the data structures. Tables and columns are the basic building blocks used to design backends.

Based on the Schema, Thin derives TypeScript bindings, APIs and Migrations.

Build Powerful Schemas

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.

Create Tables in a Git-like Workflow

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.

Add Columns

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 user_id or projects_id and Thin Backend automatically sets up the required foreign key constraints.

Auto-generated Policies

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())
    ;

Migrations

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.

Try out the Schema Designer today and see it for yourself!