@24hr/content-next 中文文档教程

发布于 3年前 浏览 26 更新于 3年前

Content Service 2.0

管道状态coverage report

What is it?

内容服务是数据源(例如 CMS)与数据将被使用的位置之间的层。 它既增加了 CMS 的功能,例如 WP,又极大地提高了性能。 它被设计为与 CMS 无关。

Why?

大多数 CMS,无论是无头的还是传统的,都需要容纳许多功能。 不管这些特性是如何解决的,最终的解决方案总是妥协的。 在某些情况下,CMS 可能速度超快但灵活性较差,或者非常模块化且对开发人员友好,但以牺牲良好的编辑器体验为代价。

最初创建内容服务是为了向 Wordpress 添加功能,例如无需双重安装的草稿实时 版本。 它还提供内存中的所有内容,使其比传统的 CMS 快得多。

How it works

Mechanics

Content Service 通常有两个消费者:

  1. A source that pushes data into it, such as a CMS
  2. One or more consumers of the data

Source

源需要以某种方式可配置,以将数据推送到 Content Service。 就 Wordpress 而言,每次在 Wordpress 中保存帖子、页面或其他任何内容时,我们都会使用挂钩来推送数据。 我们将数据从源推送到内容服务中的目标。 一个正常的设置有一个draft 和一个live 目标。 draft 始终(或应该)与源代码同步,live 仅在有人想要向公众发布内容时与 draft 同步地点。

Consumers

消费者通常是 API 或网站。 它从内容服务中获取数据并根据需要呈现数据。 消费者通常从不直接从源访问数据。 它总是从内容服务中获取数据。

MORE SOON

Concepts

内容服务遵循这些想法:

  • 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 resource as one row in the DB, and fetches that resource based on its key or externalId. It has a couple of helper functions, but not much.

Ways of using it

这还不是真的: 在当前状态下,内容服务只能用作 NPM 模块。 不存在 docker 镜像。

Docker (NOT YET)

从 docker hub 获取:

24hrservice/rawb-content-service-next:latest

NPM

npm install @24hr/rawb-content-service —save

Changes from version 1.0

  • It only uses graphql.
  • It doesn't need two instances, one for draft and one for live.
  • It's an NPM module.
  • You can have as many targets as needed (in 1.0 there was no concept of "targets". We had draft and live as 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.

Concepts

推送到内容服务的每个条目都称为 资源。 它由以下参数组成:

  • a key (required), mostly used for the slug, so that a site quickly can fetch the data for a page.
  • an externalId (required), referencing to the id of the resource, so that a change in the key can be done to a resource.
  • a parentId (optional), reference to an externalId so we can create hierarchy.
  • a type (required) used to categorize content
  • a date (optional) used to sort by date. Its value is dictated by whatever the source sees as the correct date to be used.
  • a 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.

Development

要开始开发,请执行以下操作:

cd ./dev
docker-compose up

这将启动一个数据库 (mariadb)、一个 redis 实例(用于发出事件)和一个运行它们的 nodejs 项目 NPM 模块。

Current state

MORE SOON

Features

MORE SOON

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.

Future plans

这些是我们计划做的一些功能:

  • 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.
MORE SOON

Compatibility with previous version

MORE SOON

Other parts

WP Plugin

MORE SOON

Feature Flags React module

MORE SOON

Content Service 2.0

pipeline statuscoverage report

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 .

Why?

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

Mechanics

The Content Service normally two consumers:

  1. A source that pushes data into it, such as a CMS
  2. One or more consumers of the data

Source

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 live target. 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.

Consumers

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.

MORE SOON

Concepts

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 resource as one row in the DB, and fetches that resource based on its key or 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:

24hrservice/rawb-content-service-next:latest

NPM

npm install @24hr/rawb-content-service —save

Changes from version 1.0

  • It only uses graphql.
  • It doesn't need two instances, one for draft and one for live.
  • It's an NPM module.
  • You can have as many targets as needed (in 1.0 there was no concept of "targets". We had draft and live as 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.

Concepts

Every entry that is pushed to the Content Service is called a resource. It consist of the following parameters:

  • a key (required), mostly used for the slug, so that a site quickly can fetch the data for a page.
  • an externalId (required), referencing to the id of the resource, so that a change in the key can be done to a resource.
  • a parentId (optional), reference to an externalId so we can create hierarchy.
  • a type (required) used to categorize content
  • a date (optional) used to sort by date. Its value is dictated by whatever the source sees as the correct date to be used.
  • a 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.

Development

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.

Current state

MORE SOON

Features

MORE SOON

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.

Future plans

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.
MORE SOON

Compatibility with previous version

MORE SOON

Other parts

WP Plugin

MORE SOON

Feature Flags React module

MORE SOON
    我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
    原文