Content Service 2.0
What is it?
The Content Service is layer between a source of data, such as a CMS, and where the data will be consumed. It both adds functionality to a CMS, such as WP, and drastically increases the performance. It is designed to be CMS agnostic.
Most of the CMSes out there, both headless or conventional, need to accommodate lots of features. However these features are solved, the end solution is always a compromise. In some cases a CMS might be super fast but less flexible, or very modular and developer friendly but at the cost of a good editor experience.
The Content Service was originally created to add functionality to Wordpress, such as a draft and a live version without the need of double installations. It also serves all content from memory, making it much, much faster than traditional CMSs.
How it works
The Content Service normally two consumers:
- A source that pushes data into it, such as a CMS
- One or more consumers of the data
The source need to be configurable somehow to push data to the Content Service. In the case of Wordpress, we use hooks to push data every time a post, page, or anything else has been saved in Wordpress. We push the data from the source to a target in the Content Service. A normal setup has a
draft and a
draft is always (or should be) in sync with the source and
live is only in sync with
draft when someone wants to publish something the public site.
A consumer is typically an API or a web site. It fetches the data from the Content Service and renders it as it needs. A consumer will normally never access the data directly form the source. It will always get the data from the Content Service.
The Content Service follows these ideas:
- It's NOT developed for a single specific project. On the contrary, it can be used by many different projects.
- It's NOT aware of what data it holds. This means that no feature can be written specifically for some content (for example, nothing should exists that asumes the data in a resource contant vc_content or a property called blocks).
- Everything is loaded in memory and kept there. If something changes, the cache will adapt (currently we have one place where we read from the DB, but that will be removed soon).
- It is quite stupid. It saves each
resourceas one row in the DB, and fetches that resource based on its
externalId. It has a couple of helper functions, but not much.
Ways of using it
THIS IS NOT TRUE YET: In its current state, the Content Service can be only be used as a NPM module. No docker image exists.
Docker (NOT YET)
Get it from docker hub at:
npm install @24hr/rawb-content-service —save
Changes from version 1.0
- It only uses graphql.
- It doesn't need two instances, one for
draftand one for
- It's an NPM module.
- You can have as many targets as needed (in 1.0 there was no concept of "targets". We had
liveas hardcoded targets).
- The code is cleaner. Many old things have been removed such as a fallback language, huge files and dependencies to things that should be something else.
- No direct connection with an elastic search service.
- No filters that are aware of the data each resource holds.
Every entry that is pushed to the Content Service is called a
resource. It consist of the following parameters:
key(required), mostly used for the slug, so that a site quickly can fetch the data for a page.
externalId(required), referencing to the id of the resource, so that a change in the key can be done to a resource.
parentId(optional), reference to an externalId so we can create hierarchy.
type(required) used to categorize content
date(optional) used to sort by date. Its value is dictated by whatever the
sourcesees as the correct date to be used.
host(optional) to save where the data comes from (used in rare cases to access the data from the source)
userInfo(required), to audit logs
content(required) then content itself, the main body. This is the content of the page, everything else is meta-data.
To begin development, do the following:
cd ./dev docker-compose up
This will start a database (mariadb), a redis instance (for event emitting) and a nodejs project that runs them NPM module.
Needs to be done as soon as possible
- Create a new or an updated Wordpress plugin to interact with the Content Service. The current WP Plugin is NOT compatible with this.
These are some of the features we plan to do:
- Feature flags - A list of flags with options that can be used to filter out objects in the content of a resource.
- Protected Resources - A way of making a resource not deletable.