Code-first configuration of schema, roles and permissions

[rvanoord]

It would be great if schemas, roles and permissions could be managed via code. Often custom permissions contain logic that is of a fairly technical nature and should ideally be versioned and repeatable between dev/staging/prod environments.

By supporting code-first configuration, a team of developers could collaborate on things like permission logic and easily keep their local development environments in sync via source control. Ideally permissions logic could then also be unit tested.

Currently schemas, roles and permissions are configured in the UI and stored in the database. It is of course possible to create schema snapshots and export permissions and roles via the API, however this approach does not fit naturally into a DevOps flow with multiple developers and multiple environments.

The general idea is that schemas, roles and permissions could be developed in code (e.g. yaml) and applied to the database the next time directus is started. An extension of this would be that changes made via the UI (locally) are reflected back to code and can be reviewed and committed to source control. Applying changes to production could be part of a CI/CD pipeline (e.g. Github Actions) which could use the directus API.

[VaZark]

The schema can probably be managed by,

1. ensuring that only the dev team has access to modify the tables
2. using schema commands from the cli (link)

There is also a command for creating roles

I'd love to see the concept extended to the permissions. It'd be useful to have named permission groups that can be mapped to roles.

[benhaynes]

I'd love to see this supported too. I wonder how this approach could be added to align with our current strategy...

[rvanoord]

I guess it could simply complement the current approach.

For example:

• Directus could automatically apply a code-first configuration file upon startup (perhaps similar to the current snapshot files).
• Configuration could also be applied at runtime via a cli or API command.
• If "PERSIST_CONFIG_TO_DISK" (or similar flag) is enabled, any change to the database schema, roles, permissions (or similar) would trigger generation of a new version of the code-first configuration file. This would allow changes to be made both via the Directus UI (ie. aligned with the low-code strategy) - as well as directly in code - but in each case still resulting in a configuration that can be stored in version control and applied to another environment.

Not only would this be a valuable addition for DevOps within one project, but it could also be used to create easily transportable and highly configured starter templates for new projects - without placing constraints on the underlying database technology or hosting environment.

[VaZark]

Or the persist to disk can be an event triggered which can be handled in a data flow

[u12206050]

One idea could be to expose the same file permission structure that Directus uses for AppMinimumPermissions, thus allowing developers to add permissions in code and also have them applied.

This still allows making use of the UI to add additional permissions by business if wanted.

Use case:
In code define permissions to only allow read and updates to items that match the tenantId of the $CURRENT_USER.tenantId
In UI a specific tenant might decide to add addition conditions or limit what fields are returned for a specific role (all whilst the tenant condition will always be applied)

[abdonrd]

We would love to see this!

[u12206050]

Permissions are usually applied to a specific role, although with coded config, we could allow for a more flexible structure such as extended roles and shared permissions between different roles.

How does this look:

Roles

# extensions/config/roles.yaml
- role: 2a0f6099-53da-49c0-a0de-41e7bb233259
  name: Member
  icon: person
  description: "An active member of a community"
  admin_access: 0
  app_access: 0
  
- role: e889c331-9ce0-432b-9367-9d6ef71641d8
  name: Reporter
  icon: supervised_user_circle
  description: "A reporter with insight into a community"
  admin_access: 0
  app_access: 1

- role: 77aae722-b430-4ba6-93a8-99a218dd17e6
  extends: e889c331-9ce0-432b-9367-9d6ef71641d8 # Extends the reporter role
  name: Manager
  icon: supervised_user_circle
  description: "A manager of a community"
  admin_access: 0
  app_access: 1

Permissions

FILE NAME CORRESPONDS TO COLLECTION NAME

Single role example

# extensions/config/permissions/favorites.yaml

- role: 2a0f6099-53da-49c0-a0de-41e7bb233259
  action: read
  permissions:
    userId:
      _eq: $CURRENT_USER

Multiple role example

# extensions/config/permissions/news.yaml

- role:
    - 2a0f6099-53da-49c0-a0de-41e7bb233259 #Member
    - e889c331-9ce0-432b-9367-9d6ef71641d8 #Reporter
    # NOTE: We do not have to include the Manager role, since it inherits this permission from the Reporter
  action: read
  permissions:
    community:
      _eq: $CURRENT_USER.community

[u12206050]

When imported to the database it will add the all the inherited permissions to the relevant roles as individual rows

[rijkvanzanten]

Would this also remove every other permissions record from the database during sync, or would these records be additional? (Eg would the file become the single source of truth?)

[u12206050]

It only updates (deletes and inserts) permissions for those collections that there are config files for. Since each permission should be unique per action, collection and role, it updates those that match those three columns,and removes the others. Collections that do not have config file are not touched.

…

On Wed, 4 May 2022, 16:06 Rijk van Zanten, ***@***.***> wrote: Would this also remove every other permissions record from the database during sync, or would these records be additional? (Eg would the file become the single source of truth?) — Reply to this email directly, view it on GitHub <#13041 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABSVMWWXZTBFY54OMJH27PTVIJ77PANCNFSM5URUBLOA> . You are receiving this because you commented.Message ID: ***@***.***>

[Dominic-Marcelino]

I think „Advanced custom fields” has solved this pretty well in the wordpress universe. It initially allows you to configure everything via UI, the config is stored in the db and optionally also to a local json file afterwards.

Then on each load it compares the database and file values and if they do not match it shows a Sync-Option including an comparisons overview.
This works in both directions means you can either change stuff via UI or directly in the json files.

This could also solve the problem that ist’s pretty hard to track and review permission changes.

A link to their documentation with some more details: https://www.advancedcustomfields.com/resources/local-json/

[piotr-cz]

I'm seeding initial roles, permissions and users in a custom migration.
Source code looks very similar to #13041 (comment), only difference is that it's a knex migration.

[NilsBaumgartner1994]

Could you share an example with us?

[u12206050]

#16101 Here is a PR for splitting the schema file and allowing you to more easily push only the changes you want to push to git.

[exsurgo]

From a developer's perspective, this is a critical feature. With most ORMs, you define your schema in a single location, and they auto-generate tables/code/etc. For my current workflow, I create TypeScript interfaces first, then I have to create the actual schema in the UI. Plus it makes migrations and deployments more difficult. This is repetitive and tedious.

In a perfect world, I'd love to see an ORM approach using decorators (similar to TypeORM or VuexORM). Something like ...

import { Item, collection, field, role } from '@directus/schema'

@collection({
    name: 'jobs',
    icon: 'ads_click',
    note: 'A collection for displaying jobs',
    display_template: '{{title}}',
})
@role('employer', {
    permissions: ['read', 'create', 'update', 'delete'],
    // Employers can only update their own records
    validation: { company: { _eq: '$CURRENT_USER.company' } },
})
class Job extends Item /* Provides base fields, created/updated, status, etc. */ {
    @field({
        is_primary_key: true,
        auto_increment: true,
    })
    id: number

    @field({
        interface: 'input',
        max_length: 50,
        trim: true,
    })
    title: string
}

You could then define all of your collections/fields/roles/permissions/etc. in local code alongside your models, and have them automatically synced without ever having to touch the UI.

[rijkvanzanten]

@VaZark Good idea! Currently the custom migrations go "straight" to the database through knex, so we don't really have a good way to accurate capture the changes made, as it's effectively raw SQL. I think an important step for all of this is to have a "directus standard" migration file style, that relies on some known standard set of operations that we can track in static form

[exsurgo]

@rijkvanzanten I think the main benefits of decorators would be the ability to define everything in one place, type safety, and having OOP/inheritance. Admittedly, it gets tricky with plain JS. You can use decorators in JS, but it requires a transpiler like Babel or TS. Decorators are in stage 3 proposal though, so they are expected to land at some point. There could be a couple of ways of defining the schema, functional (as @u12206050 suggested) and decorator based. As far as applying changes, it could happen mostly automatically on init or via CL (at least for new fields/collections, renames, etc.), though obviously manual migrations would be needed for complex changes.

@falmanna I agree that models should be able to serve as the "source of truth", like Django and other ORMs (RoR, TypeORM, Sequelize, Hibernate, etc). Developers change the model structure/definition, and those changes are reflected in the DB schema (as much as possible). This might be challenging with 2-way generation, but I think it could be done.

[Dominic-Marcelino]

Currently the custom migrations go "straight" to the database through knex, so we don't really have a good way to accurate capture the changes made

Not directly related to the code-first topic, but maybe once this task starts it would also be an opportunity to implement some kind of versioning / activity / change-tracking for the roles and permission. 🤔 Feels a bit weird that directus is capable of tracking changes everywhere except of roles and permission (where I'd expect more or less the most)

[VaZark]

I think an important step for all of this is to have a "directus standard" migration file style, that relies on some known standard set of operations that we can track in static form

A good start might be creating a list of possible actions per collection/views.. from the App, then building a superset of on top of it for allowed actions from scripts and someway to store raw queries? 🤔

[piotr-cz]

Not directly related to the code-first topic, but maybe once this task starts it would also be an opportunity to implement some kind of versioning / activity / change-tracking for the roles and permission. 🤔 Feels a bit weird that directus is capable of tracking changes everywhere except of roles and permission (where I'd expect more or less the most)

I agree.
I can update most of the schema with a snapshot, but for updates to roles/ permissions I need to write migrations every time.

[abdonrd]

I really like this idea of code config; in fact, in the absence of this functionality, we are using migrations to apply changes across all environments. But it is quite uncomfortable.

[badrange]

Before I found Directus was working with Drupal for years. One of the few things where Drupal has an advantage over Directus is configuration management - it's not perfect BUT it has been battle-tested over a period of many years in every environment and project setup you can imagine. Drupal has a concept of "content types" that are basically database tables (but the structure is mind blowingly complicated) to which you can add fields of different types and with different display modes.

They have found a quite clear distinction between configuration and content, and they have built in the option of overriding config per environment (for example an extra set of modules for developers that are only active in development; production specific configuration only in production).

I think you could benefit from getting inspiration from that project; either by looking at documentation/code and/or by discussing the implementation (and challenges they've overcome!) with some of the developers.

[drennvinn]

That's exactly what I wanted to say.
I loved using the config sync system with drupal. Being able to versioning, import/export config files along dev/staging/prod platforms is dope!

[rijkvanzanten]

Heya! Thanks for opening this feature request!

This feature request has received over 15 votes from the community. This means we'll move this feature request to the Under Review state!

The Core team will schedule a meeting to review this request as soon as possible. The discussion will then be approved or denied. You may or may not be invited to join this meeting with the core team.

For more information, see our Feature Request Process.

[rijkvanzanten]

Dear reader, also make sure to take a look at #17495, which discusses the same goals in slightly different ways 🙂

[rvanoord]

Very exiting seeing this suggestion (and #17495) making it into Review :-)!

I was just reflecting on the original title "Code-first configuration of schema, roles and permissions". I just wanted to iterate that it wasn't being able to work with code (instead of the UI) that was the primary objective (as the title may imply), but more as mentioned in #17495 - supporting a team-friendly, versionable, reviewable, multi-environment deployment workflow for both schema and configuration. A workflow that allows developers to configure Directus locally and review/deploy changes via a CI/CD workflow.

I think it makes sense to be able to configure which parts of the configuration are considered "application logic" on a per-project basis.
The line probably goes between what developers are managing and what the end users are managing. E.g. if permissions are managed by developers, they essentially become part of the application logic and should be persisted to a file-based configuration. The same could apply to things like dashboards.
On the other hand, if the end users are creating their own dashboards or configuring permissions themselves - then this might be considered environment-specific application data (and use database as the primary store).

[CapitaineToinon]

What's the expected way for us to approach this issue right now? Are there any examples online of actual code bases using stuff like custom migrations with knex and schema snapshots?

[u12206050]

Ideal would be generating diff migrations thereby no matter the state of environment you would be able to run migrations in correct order.
Currently Directus migrations and custom migrations are detached from each other and don't run in order, causing possible issues such as Custom migrations executing on a new Directus state than when the migration was first created.

Both full snapshots (for test ci/cd) and diff snapshots (for live environments) should be supported.

[falmanna]

Currently we have a custom migration pipeline that applies the following in order:

1. Directus migrations
2. Custom migrations
3. Snapshots
4. Data migrations (roles, rbac, etc)

It is still not perfect, but working fine.

We were also thinking about moving away from custom knex migrations to a completely separate tool like Prisma, it has the added benifit of generating types and models that can be used in our extensions.

[benosman]

We've been using diff migrations for a while and that issue with the Directus and custom migrations order that @u12206050 mentioned has bitten us. We had to edit some of the historic migrations to get it to work on a new Directus instance.

How ours works:

• we add a few extra cli commands, primarily one to generate a diff either between two snapshots or between the current instance and a snapshot. It was created before the snapshot endpoint was introduced, but now it utilises the Directus get-snapshot-diff function with just a few tweaks to the output to split into up/down diffs
• we then have a custom migration template where we paste in the json output of the above into as a const, and reformat the file in vscode. The resulting migration file has up and down migration steps which get the relevant diff from the constant and call the directus function apply-diff.
• when deployed to production, the custom migration runs on bootstrap and brings the production database into line.

It generally works pretty reliably, we want to update the cli command to output js/ts with the full migration script to save the manual step, but we've been holding back to see the direction of any official/recommended approach. We also look through the diff before committing to make sure the right collections / fields are being modified.

The issues we do have with it are related to our workflow. We have local environments, a shared dev instance, staging and production. No manual schema changes should be made on staging or production.

Our backend developers work locally and often create new collections using a derivative of the schema builder kit, which allows us to create custom migrations easily. which are more compact and legible than the diff approach above. It doesn't support modifiying fields or collections yet so we use diff approach for that.

We also have frontend developers that use the data studio on the shared dev instance of directus to add collections, fields and relationships. When they are ready to deploy those changes, a backend developer fetches a snapshot from the dev instance (now using the endpoint, previously using the cli) and runs the diff command mentioned above. There is the manual step of making sure everything in the diff can make it's way to prod, sometimes there are changes from other developers which are not ready, so we don't yet have an easy way to isolate those changes from the diff.

Once the diff is ready, it gets added to the migrations but probably the main issue is that the diff is created between the local instance which should match production and the snapshot for the dev instance. However, once the migration is pushed to git, the CI builds the directus image and as part of our pipeline it gets deployed to our dev instance. So by default, the diff migration would fail as those changes are already present. We don't yet have an elegant way to mark the migration as effectively run, but do have a workaround in place not to have the migration fail.

We do run other instances for specific isolated features, but it is difficult to keep them in sync with the regular pipeline, if we have them on the same codebase then they have to run the diff migrations which we may not want, but there may be other changes we do want.

In summary, while it is working ok for us, we'd consider a declarative approach as it may work better in our workflow. The currenet snapshot approach does fail though for us as the file is too large due to the number of collections we have. Even if we split the files up, the way that the apply snapshot process deletes collections that are missing from the snapshot would likely cause issues for us as we deploy into multiple environments. For instance every change on a local instance would need to fetch the current dev snapshot (some of which may be a work in progress), otherwise when it gets deployed to dev it would wipe out all the recent changes there.

Then of course there are the issues with permissions, flows, and content which we have a different sync process which is still a work in progress.

[MoaathAlattas]

I have experience working with Django and another headless CMS in the past and I like how the migrations/developer-flow is handled in both.

In Django, first you define the schema in files and run a command to generate a migration file. Basically, a migration file is just instructions to apply the changes necessary without, relying on another environment state. This is important because once you have multiple developers working on a project the snapshot could get out of sync at any point. See makemigrations, migrate. Also, one feature is really helpful when developing is unapplying migrations migrate which allows you to rollback the schema to a certain state.

In the other headless cms, there is a concept of branches where you can create a copy of the current environment (a new branch), make schema changes on the UI, connect to the new branch as a developer and testing on my client. After done development, I can either merge those changes back the main branch or download a migration file. Downloading the file is amazing because it allows me to:

1. store them in my repo and be able to generate the same schema/configuration form scratch.
2. integrate it into my pipeline as a step before deploy where you apply the changes then deploy my app (client). This is helpful if i don't want to allow merging configuration changes on the UI.

I still prefer the idea of starting to create schema changes, adding roles, or configure permissions on the UI rather than generating migration files manually because I love Directs UI and it is way faster/easier to create, setup and experiment.

I have been experimenting with DrizzleORM recently to manage migrations outside of Directus just to find out how this could be managed. I did the following so far:

• Make the changes on Directus UI
• Run a command to generate schema change and Directus configuration diffs. This is a combination of:
  • DrizzleORM (introspect--pull) to get the new tables.
  • a custom script that, during runtime, merges all existing diffs to get the state before changes, then compare it to the new state and generate a new diff.
  • the diff will be stored as a file and translated to sql to create a custom sql migration. This is to make sure all migrations run in the right order.
• Now I can apply migrations using DrizzleORM migrate feature.

Looking forward to see this implemented in Directus 🌟

[w0kyj]

• Reference Issues / Discussions:
  • Code-first configuration of schema, roles and permissions #13041
  • Environmentalized deployments and config-file based approach #17495
  • Deployments: Generate Schema File and Content Migrations #3891
• External References & Examples:
  • YANG - https://en.wikipedia.org/wiki/YANG
    • Similar functionality
  • Docker Compose
  • Kubernetes Helm

Summary

Add Directus code first configuration management to the current API/App features to enable better devops, templating, environment migrations and general reusability of any project.

Currently schemas, roles and permissions are configured in the APIs or Studio App and stored in the database. It is of course possible to create schema snapshots and export permissions and roles via the API, however this approach does not fit naturally into a DevOps flow with multiple developers and multiple environments.

The general idea is that schemas, roles and permissions could be developed in code (e.g. yaml) and applied to the database the next time directus is started. An extension of this would be that changes made via the UI (locally) are reflected back to code and can be reviewed and committed to source control. Applying changes to production could be part of a CI/CD pipeline (e.g. Github Actions) which could use the directus API.

Basic Example

Code first concept(similar to the current custom extensions implementation):

A group of config folders:

• Data Model (Schemas)
• Project Settings
  • Branding & Style (includes assets)
  • Security
  • Files & Storage
  • Mapping
  • Image Editor
  • …
• Roles & Permissions
• Presets & Bookmarks
• Translations Strings
• Flows
  • Operations
• Dashboards
  • Panels

When populated by one or more yml files inside, Directus will apply to project & database

Motivation

Use Cases:

• By supporting code-first configuration, a team of developers could collaborate on things like permission logic and easily keep their local development environments in sync via source control. Ideally permissions logic could then also be unit tested.
• Users would like to test how Directus works, but not from a blank canvas perspective. A code-based approach that is database agnostic and deploys a template configuration to jumpstart the experience.
• Debugging — when an issue identified, users could share their configuration that reproduces the problem. Reduce time to replicate the issue and fix it.

Detailed Design

Requirements List

Must haves:

• Code configurations for all project administration settings
  • Project Settings, Data Model
  • Roles & Permissions, Translations Strings, Flows
  • Presets & Bookmarks, Insights Dashboards & Panels
• Import/Export
  • Import considerations:
    • How to define what gets imported?
      • Merge with existing schema
      • Overwrite existing schema (if deleting data model — content will also be deleted)
    • What happens on collision with existing data?
      • Auto overwrite
      • Log and ignore
      • Log and rollback to original state
  • Export considerations
    • Multiple file exports:
      • Set organization using the Admin groups (Project Settings, Data Model, …) as top level folders?
      • Selective export — user can choose which components
        • eg I have 10 collections, 3 roles, 8 presets total, …
          • Does this export all no matter what?
            • Specify specific exports — 5 collections, no roles, 3 presets, …
• Solution for handling secrets/tokens/hashes
  • Externalize secrets

Should haves:

• modular files with extensions
  • Think single file per collection (makes them reusable across projects)
  • Extensions allow fast one off configurations (add a specific field to existing collection)
  • Extend existing / public schema files
  • Import snippets from other files (like individually nested collections)

Could haves:

• Only save non-defaults in schema file(s)
• Dynamic Configuration Sync
  • Changes made in Data Studio sync’d to configuration files
  • Changes made in configuration files sync’d to deployment
  • Possible options:
    • Automatic real time sync - setting to enable
    • Manual
      • button option in Data Studio or API triggered
      • Cron option to sync periodically
      • How to handle merge conflicts?

Will not have:

• [ ]

[badrange]

Suggestion for another reference: Drupal. The project started with yml based configuration export/import in Drupal 8 that was released November 2015 and have refined it for nearly a decade to work in any hosting/development process imaginable.

[beasteers]

Some inspiration for UI to manage this through Git is Nodered Projects

[EdouardDem]

Hi, I've just built a tool called directus-sync that could help streamline the way we handle Directus configurations and schema management. It’s inspired by the principles of infrastructure-as-code, with a touch of the familiar workflow from Terraform. This is currently a beta release, and I’m seeking collaborators who are up for testing, providing feedback, and contributing to its evolution. Check out the repo and let me know what you think!

[phazonoverload]

On January 25 we're inviting you to come and have a chat with us about this feature request at our Request Review in our Discord server. This will help us have some dedicated time to talk about what implementation would have the most sense. Please feel free to join us as https://directus.chat (the event is already listed and you can set a reminder)

[w0kyj]

NOTES: January 25, 2024 Request Review

• Import Export Considerations:
  • Allow for long running process for large schema
  • Maintenance mode to prevent changes while an import/export is running
  • consider split between config and content for data formats
    • config as JSON or YAML or …
    • content as delimited files or …
  • dynamic collection / field names e.g. for importing an third-party template while choosing your own "target" names
• Resources:
  • https://github.com/aws/aws-cdk
  • https://github.com/directus-community/schema-builder-kit
  • https://hasura.io/blog/announcing-hasura-data-delivery-network-alpha/
  • prisma migrations are an interesting way of doing things - they have a custom format which is more concise than the directus yaml, and then some cli tooling that creates sql migrations and syncs environments. I think behind the scenes it uses a shadow database that keeps track of state. https://www.prisma.io/migrate

Recording of the session will be available on Directus TV in a few days:

• https://directus.io/tv/request-review

[u12206050]

This has been solving our needs in 5 of our DIrectus projects so far with a team of 5 users: https://github.com/bcc-code/directus-schema-sync

Also if you need to start from scratch (ie. testing environment in Docker) we have this script that installs Directus and import schema and data from schema-config on a fresh database:

Download the init.mjs file and add it to the project root then in package.json under scripts add init: node init.mjs
On a fresh database you can then run npm run init
init.mjs.zip

[Sandros94]

Looks like Apple just released a configuration as a code language named Pkl, might be something useful to keep an eye on.

From their use cases:

[...]
By generating this configuration with Pkl, you can reduce verbosity and increase maintainability through reuse, templating, and abstraction. JSON, YAML, and XML property lists are supported out of the box; renderers for other configuration formats can be developed and shared by anyone. Automatic defaults, strong validation, and sensible error messages come in reach with configuration schemas.
[...]

From their concepts:

[...]
Modules can reuse other modules by importing them from local or remote locations. Imports can also be used to split up one large module into multiple smaller ones, increasing maintainability. A configurable security policy helps to keep imports under control.
[...]

if I understand this part correctly it could be useful to us to define a single source of truth for things like official Directus's collections making them readable, referenceable and expandable.

This language's strong points seems to be about: Schema generation, Modularity, Templating and Type safety. Basically one of the two aspects we needed for this discussion, leaving only the "data" question to be solved.

[rijkvanzanten]

Interesting! Reminds me of https://kdl.dev/

[Sandros94]

Interesting! Reminds me of https://kdl.dev/

Never heard of it and yes indeed

[sloonz]

I heard about KDL a few months ago, forgot the name, and spent last weeks desperately trying to find it again without success — thank you very much for finding it !

[1cedsoda]

Locked Mode

There should also be a locked mode, where it's only possible to change data, but not schemas, permissions and so on in a production environment. Could be enabled by an environment variable or something similar outside the application.

This would make sure a production environment is predictable.

[u12206050]

This little hook can help you achieve that:

import { createError } from '@directus/errors';
import { HookConfig } from '@directus/extensions';

const FORBIDDEN_IN_ENV = createError('FORBIDDEN', 'This action is not allowed in production', 413);
function stopIt() {
	throw new FORBIDDEN_IN_ENV();
}
const registerHook: HookConfig = async ({ filter }, { env }) => {
	if (env.DISABLED_ADMIN) {
		['collections', 'fields', 'relations'].forEach(table => {
			filter(`${table}.create`, stopIt);
			filter(`${table}.delete`, stopIt);
			if (env.DISABLED_ADMIN === 'INCL_UPDATES') {
				filter(`${table}.update`, stopIt);
			}
		});
	}
};

export default registerHook;

[binaryben]

I don't know if it's been suggested yet, but I would love to be able to define my models/tables as Database Markup Language (DBML) files and then have Directus figure out the required migrations based on them.

I love the idea of being able to write docs as code which generates the database at the same time. Plus automated typing and voila! Everything is always in sync. I think DBML is also arguably a bit more accessible for non-traditional developers. Great for those who want a way to define their data schema as code even if they're not particularly fluent in Typescript (or any language for that matter)

Could also be used in the Directus App to visualise the relationships as well

[rijkvanzanten]

Hadn't seen DBML before. Very interesting!

[Sandros94]

What an absolute beast this is! Thanks for pointing it out.

P.S.: I can finally stop drawing relationships in MS Paint when reviewing with non-dev clients 😜

[binaryben]

P.S.: I can finally stop drawing relationships in MS Paint when reviewing with non-dev clients 😜

If you are serious, I cannot express how very welcome you are! Go, be free of MS Paint!

[ricricucit]

This it IT.
Super suggestion, @binaryben!

[jofmi]

Want to share an experimental tool for a code-first configuration of Directus within a Nuxt app. Maybe some of the ideas in it can be interesting for the discussion here :)

The repo is here: https://github.com/jofmi/directus-nuxt-migrations

I like this approach because it lets you declare modular database schemas within a Nuxt app and migrate them to Directus via the SDK.

This makes it possible to write Nuxt modules that include frontend code, custom API endpoints, and the Directus database structure in one publishable package - similar to how I was used to it in Django.

Another idea that I had was whether it is possible to write something like a Drizzle ORM adapter for Directus.

[almereyda]

I'd like to second the notion of having a Drizzle-like adapter. "Push migrations", as they are also offered by Supabase, seem to be the way to go for the future.

More about this pattern in:

• Safely making database schema changes
• Comparison of Online Schema Change tools — PlanetScale Documentation
• How Online Schema Change tools work — PlanetScale Documentation

Because in general, combining TypeScript with GraphQL and SQL is a great mess. (Entwicklungsweisen dynamischer Webseiten - allmende - Allmende I/O Meta [German])

[jofmi]

Just to have it here as well, Pocketbase also has an interesting approach, where it automatically creates migrations as you change the schema in the UI: https://pocketbase.io/docs/js-migrations

[ssnaruto]

Hi, has anyone used zenstack? i see there are a lot of things similar to directus permissions configuration but as a DSL language. Row and column level security, validation... is it possible to use zenstack in directus?