Skip to content

Latest commit

 

History

History
194 lines (137 loc) · 6.7 KB

FINDINGS.adoc

File metadata and controls

194 lines (137 loc) · 6.7 KB

VPRO STRAPI poc

Building

You can either use yarn or npm. Requirements:

  • Database (postgresql) or sqlite (which requires python)

  • Node 18

  • npm or yarn

Installation

Create the database

psql

postgres=# create user "strapi" password 'strapi';
CREATE ROLE
postgres=# create database "strapi-poc" owner 'strapi';
CREATE DATABASE
postgres=# grant all privileges on database "strapi-poc" to strapi;
GRANT

Build

Is this step required ?

npm install

Create project

Settings for the next step:

  • Choose your installation type Custom (manual settings)

  • Choose your preferred language TypeScript

  • Choose your default database client postgres

  • Database name: strapi-poc

  • Host: 127.0.0.1

  • Port: 5432

  • Username: strapi

  • Password: strapi

  • Enable SSL connection: No

npx create-strapi-app@latest strapi-poc

Running

First change directory to the project directory (strapi-poc), the one with the filled in .env file.

  npm run develop
  Start Strapi in watch mode. (Changes in Strapi project files will trigger a server restart)

  npm run start
  Start Strapi without watch mode.

  npm run build
  Build Strapi admin panel.

The default installation lives at: http://localhost:1137/admin On first run you are asked to create a admin user.

=== Forget password:

 npm strapi admin:reset-user-password --email="[email protected]" --password="Admin2000k"

Migration

I performed a test migration here

Remarks

Ids

Ids are integers. So could not use uuid. So needed to store the original id in a separate field.

Schema in code

Seems nice, for an article type for instance it is stored in: dist/src/api/article/content-types/article/schema.json

Authorization

Similar to other systems (prepr, directus) There are 3 roles. Author: may create and edit their own object.Editor: may edit all objects. Admin: may do everything. You can create new roles, which can have permissions per table 'content type'. You can also limit access to plugins and other parts of the system. Ie, the content-builder or the media-library.

Multi tenancy

In https://strapi.io/blog/how-to-build-a-pseudo-multi-tenant-application-in-strapi there is a partial solution described. Which is actually just running multiple strapi instances. They do however share the same codebase and schema.

Authentication

Defaults to users in database.

SSO is available when you have an enterprise license see https://docs.strapi.io/dev-docs/configurations/sso. Which makes this https://strapi.io/blog/how-to-add-a-custom-o-auth2-open-id-connect-provider-to-strapi-v4 curious. As it seems to provide similar functionality (code at https://github.com/ChristopheCVB/strapi-custom-oauth). However that solution looks a bit more hacky/incomplete than the official one.

There is a plugin online (https://gitlab.com/hipsquare/strapi-plugin-keycloak), but it seems limited. It is not made for admin users, and is also not usable with the graphql endpoint. It seems to be built voor route protection not actual editor logins.

Workflow & Publishing

Publishing is explained at https://docs.strapi.io/user-docs/content-manager/saving-and-publishing-content It says that any object can be draft or published. This is done with the 'published_at' field, which is null for drafts. However this not seem to protect draft objects to be retrieved through the api. They are excluded by default but can be retrieved by passing a _publicationState=preview parameter, see https://forum.strapi.io/t/draft-and-posted-entities/3576 for details.

Scheduled publication is not present at default, but can be created by adding an extra date field and use a cronjob to change the publication status. See https://forum.strapi.io/t/schedule-publications/23184 for more information.

Images

Images are stored in the media library, this is by default on the file system, but a s3 provider is available (https://strapi.io/blog/how-to-set-up-amazon-s3-upload-provider-plugin-for-our-strapi-app) The image do not have metadata, so metadata needs to be managed through a related object.

Image rendering is done on upload/save, a set of resolutions is generated at that time. The list of resolutions is configurable.

There also options for other storage providers. For instance cloudinary: https://market.strapi.io/providers/@strapi-provider-upload-cloudinary This requires some configuration but seems to integrate well.

Richtext

Rich text is stored as markdown. So during conversion we need to convert the html to markdown. The editor is not configurable. Images are stored as links to the original size image. There are only hyperlinks

There are plugins available which can make this a ckeditor, mceditor and others.

API’s

There is a straighforward REST API: https://docs.strapi.io/dev-docs/api/rest

There is a graphql API: https://docs.strapi.io/dev-docs/api/graphql as a plugin.

Plugins

npm strapi install graphql

Development

Using the content-type builder is in principle nice, but as soon as you save the server restarts. Not exactly friendly.

Custom field types

I haven’t done this yet, but there are plugin which do stuff like 'country select' and 'encryptable field', which probably proofs that most things we might want are possible without support.

Frontend demo’s

svelte

I tried svelte, but didn’t quite get thins working.

flask

Falled by to flask. That went beter. The index page was working. Doing more complicated graphql e.g. with filtering on uuid, was not working, and doesn’t seem so easy to figure out.

Bugs

  • I started with a collection type '3voor12update', which just gives errors. Drievoor12update works.

  • http://localhost:1337/admin/list-plugins is something giving empty responses

  • Default it is watching all kind of silly stuff, like .adocs…​

Conclusions?

  • STRAPI too seems to be a straight forward headless cms.

  • Backend by a relational database

  • Can be self-hosted easily

  • Develop in development mode, which may change local files, which can be simply committed then.

  • ids are integers.

  • The api is not separate.

  • There are plugins available for all kind of things.

  • Workflow is limited and requires custom work.

  • There is a discord community

  • Database schema is stored as a json

  • Images have fixed sizes

  • Richtext is very limited out-of-the-box

  • SSO is an enterprise feature

  • Multi tenancy requires multiple instances.

  • Draft items are publically available (with an API key)