cms

This document briefly describes the approach to CMS implementation.

CMS requirements

• Standalone microservice with API access
• As quick as possible content access
• Admin content entities operations (CRUD)
• User content entities operiations (all entities, one entity)
• Entities versioning
• Entities validation against some schema or set of rules
• Authentication with JWT (isaac, not a CMS requirement actually)
• Restrict access to content entites by scope (multitenant???)

Approach

As we don't need to serve any static content (because of SPA) we just need to implement simple and lightweight API that will allow us to manage some user content with a minimum possible delay.

Fast API with CRUD

The suggestion is to use Maru framework with PostgreSQL as a storage.

API should have separate namespace for users and admins. For example: GET: /v1/public/posts and POST: /v1/admin/posts. Ofc all of the above are discussionable.

Entities versioning

Versioning made with PostgreSQL extension called temporal tables.

TL;DR

Temporal tables creates specific datatypes and functions in psql.

If we need to track versions of a table, we just creating a new table <table_name>_history and trigger versioning_trigger on table we want to track.

The rest made by temporal tables

Finally we have <table_name> containing where only the last versions stored, and <table_name>_history with all versions <table_name> had.

Whole approach described in that blogpost

Entities validation

To validate entities we can use Vex. Vex is a data validation library for Elixir. It can validate any datatypes against any criteria.

Authentication with JWT

All authentication made in isaac by JWT token, so no need to think about it.

Restrict access to content entites by scope

We can fetch current scope from the user JWT token and then allow current usr to manage only entities allowed for his scope.

Engineering

All entities in the CMS are instances of specific content-type.

Content-type aka schema is a JSON document describing one or the other content-entity in the CMS. It contains all fields with field types and/or any other restrictions (required field, non_neg_integer, email, URL, etc)

We can start with our current object schemas and then go forth and develop it like we would like to.

For example:

{
  "$schema": "http://json-schema.org/draft-04/schema#",
  "type": "object",
  "widget": "price",
  "properties": {
    "currency": {
      "type": "string",
      "minLength": 3,
      "maxLength": 3
    },
    "value": {
      "type": "number",
      "minimum": 0,
      "default": 0
    }
  }
}

Presumably we will have some predefined content-types which will be restricted from editing by the user (by scope).

Users are free to create new content-types and edit content-types created by them.