Making EmDash CMS Headless

[sempostma]

If we already have data access nicely isolated to repositories (https://github.com/emdash-cms/emdash/blob/main/packages/core/src/database/repositories/content.ts), why not make these abstract and allow for different implementations?

This is a backend implementation for Decap CMS: https://github.com/laikacms/laikacms — it uses abstract repositories. It can work with anything you can build an implementation for, such as flat files, SQL, or other APIs. In Laika CMS I implemented R2, GitHub, the filesystem, D1, and several others.

For example, if I don’t want to give EmDash full database access, I could build an API around my database and create an API-based implementation for the content repository that proxies requests to another worker.

Since EmDash CMS is still in early development, this could still be implemented relatively easily.

There are disadvantages, of course. Tight coupling makes some things easier to implement—you don’t need to deal with edge cases for specific implementations, for example.

However, I think the advantages outweigh the disadvantages. And not all repositories need to be abstract. The only really important one is the content repository.

[sempostma]

The easiest way to achieve this would be to make the repository/repositories abstract and move them into a separate package to avoid circular references. Then a default implementation could be created using the exact same code that currently exists in the repositories directory (SQL).

A "persistence" option could then be added to EmDash CMS, allowing users to provide their own custom persistence layer. If none is provided, it would fall back to the default implementation, so absolutely nothing would change for existing users.

These concepts are inspired by:
https://github.com/laikacms/laikacms/blob/main/docs/architecture.md

[sempostma]

To clarify, Our usecase is to use a different kind of database, and instead of supporting each database seperately. Making it agnostic from the beginning (or only for content) would be very helpful. I also have an issue with running React in the same runtime as where all my environment variables live due to all the recent CVE's around React server components.