14ヘッドレスCMS 2019のレビュー

しばらく前、私が働いていたロシア市場のある有名な公開会社で、ヘッドレスcmsの使用について疑問が生じました。 多くの実装の中で、 1つを選択する必要がありました。 これは、選択基準を作成する方法、cmsを分析する方法、およびこの分析によって自分で書く必要があると思うようになった方法についての話です。 カットの下の14のヘッドレスcmの概要。

ヘッドレスCMSとは何ですか？

この用語は新しいものではありませんが、何らかの理由で、このトピックはロシア語のインターネットではほとんど取り上げられていません。 ウィキペディアによると：

ヘッドレスコンテンツ管理システム 、またはヘッドレスCMSは、コンテンツリポジトリとしてゼロから構築されたバックエンドのみのコンテンツ管理システム（CMS）であり、デバイスに表示するためにRESTful APIを介してコンテンツにアクセスできるようにします。
ヘッドレスコンテンツ管理システム 、またはヘッドレスCMSは、サーバーベースのコンテンツ管理システム（CMS）です。これは、最初はコンテンツのリポジトリであり、RESTful APIを介して任意のデバイスに表示するためのコンテンツへのアクセスを提供します。

つまり、ヘッドレスcmsは概念であり、cms-okの特別なタイプの一種であり、cmsは「純粋な」コンテンツの管理のみを担当します。 これにより、cmsで管理されるデータレイヤーを、クライアントアプリケーションによって制御される表示レイヤーから分離できます。 コンテンツは、通常はJSON形式のユニバーサル形式で配信されます。これにより、Webサイト、モバイルアプリケーション、およびインターネットに接続されたデバイスを同時に管理できます。

このような概念の長所と短所の詳細については、この記事 、またはこの 記事 、またはウィキペディアの記事を参照してください 。

コンテキストに没頭する

検索基準を決定し、どのヘッドレスcmsが他のcmsよりも優れているかを理解するには、質問に答えなければなりませんでした。 どの特定のタスクをどのように解決する必要がありますか？

現在の一連の思考を実証するために、典型的な問題を思い付き、ヘッドレスcmsの1つを使用してそれを解決しました。 そして実際にはすべてがわずかに異なっていましたが、そのような物語の形式は本質を簡潔に反映し、頭のないcmsのトピックをよりよく明らかにしています。

だから、タスクが開発に来ると想像してみましょう。 このサイトでは、ユーザーが映画のレビューを読むための新しいセクションを実装する必要があります。
条件は次のとおりです。

• 現時点では、映画の名前、ポスター、監督の名前、およびレビューのテキストのみを表示する必要がありますが、将来的には構造がより複雑になり、料金、俳優などに関する情報が表示されます。
• 技術的背景のない人、コンテンツマネージャーは、レビューを追加および変更する必要があります。このため、開発リソースは関与すべきではありません。
• この機能は無効にする必要があります。 機能切り替えを実装する必要があります。
• コンテンツを公開する前に、コンテンツマネージャーは、テスト環境で編集がどのように見えるかを確認できる必要があります。

これらは、内部顧客からの要件です。 開発側には、実装に関する独自の技術的ビジョンがあります。

• 顧客は膝を撃てないようにする必要があります。 コンテンツマネージャーは、たとえ彼が望んだとしても、何も壊してはいけません。 開発者が想定したもののみを編集する必要があります。
• バージョンを管理し、何かが発生した場合にロールバックできる必要があります。
• 将来どのような機能が追加されるかはわかりません。つまり、セクションの複雑化や変更は簡単なはずです。
• セキュリティ側：システムは、奇妙なクラウドではなく、サーバー上にある必要があります。 オンプレミスで展開できる必要があります。

まあ、タスクは明確です。 決定に移ります。

Any JSON CMSを使用します 。これは、ヘッドレスcmsの1つです。 現時点では、上記のすべての要件を満たしているわけではありません。 たとえば、コンテンツマネージャーは、テスト環境で編集がどのように見えるかを確認できません。 ただし、すべての長所と短所は後で表示されます。 今、私はあらゆるヘッドレスcmsを扱う典型的なシナリオを「感じ」ようとしています。

最初に行うことは、モデルを記述することです。 モデルは質問に答えます。コンテンツエンティティはどのように見えますか？ 彼女の構造は何ですか？ 本質的に、これはcmsとクライアントアプリケーション間の相互作用のプロトコルです。 私たちの場合-映画のレビュー-オブジェクトには以下が含まれます：

• 3つの必須プロパティ：映画のタイトル、映画のポスター、レビューテキスト。
• 1つのオプションプロパティ：オブジェクト「director」には、2つの必須プロパティ名と姓が含まれます。

JSONスキーマとして、概要モデルは次のようになります。

{ type: 'object', required: ['movieName', 'moviePoster', 'reviewText'], additionalProperties: false, properties: { movieName: { type: 'string', minLength: 1, maxLength: 300, }, moviePoster: { type: 'string', description: 'URL to file', }, movieProducer: { type: 'object', required: ['name', 'surname'], additionalProperties: false, properties: { name: { type: 'string', maxLength: 100, minLength: 1 }, surname: { type: 'string', maxLength: 100, minLength: 1 }, }, }, reviewText: { type: 'string', minLength: 1, maxLength: 3000, }, }, } 

また、機能の切り替えを実装する必要があります。JSONスキーマの形式のモデルは次のようになります。

 { type: 'object', required: ['isFeatureActive', 'name'], additionalProperties: false, properties: { isFeatureActive: { type: 'boolean' }, name: { type: 'string', enum: ['movieReviewFeatureToggle'] }, }, } 

モデルの外観を理解したら、任意のJSON CMSでモデルを作成できます。



私はすぐにコンテンツエンティティ、つまり モデルに基づいたコンテンツ自体。 1つのダミーレビューと機能切り替えエンティティ。



クライアントアプリケーションをcmsと統合するには、APIキーが必要です。 対応するセクションcmsで生成します。


これで、クライアントアプリケーションでの機能の実装とcmsとの統合の準備がすべて整いました。 クライアントアプリケーションは何でも構いません-Webサイトまたはモバイルアプリケーション、あるいはその両方で、何でも書かれています。 例として、ReactのSPA Webサイトに機能を実装します。 実際、CMSから既知の固定構造を使用してデータを取得し、希望どおりに表示します。

 import React, { Component } from 'react' import { Accordion, AccordionItem, AccordionItemTitle, AccordionItemBody, } from 'react-accessible-accordion' import 'react-accessible-accordion/dist/fancy-example.css' const apiUrl = 'https://api.anyjsoncms.com' // ApiKey      const apiKey = '87414950dfd15648ea560bd89dd0ee02bfc8fcca' class App extends Component { constructor(props) { super(props) this.state = { movies: null, isFeatureActive: null, loading: true, } } componentDidMount() { const options = { method: 'GET', headers: { ApiKey: apiKey } } Promise.all([ fetch(`${apiUrl}/entries?apiId=featureToggle`, options).then(resp => resp.json() ), fetch(`${apiUrl}/entries?apiId=movieReview`, options).then(resp => resp.json() ), ]) .then(([featureToggleResp, movieReviewResp]) => { const featureToggle = featureToggleResp.find( item => item.value.name === 'movieReviewFeatureToggle' ) const isFeatureActive = featureToggle && featureToggle.value && featureToggle.value.isFeatureActive const movies = movieReviewResp.map(item => item.value) this.setState({ movies, isFeatureActive, loading: false }) }) .catch(error => { console.error(error) }) } render() { const { movies, isFeatureActive, loading } = this.state if (loading) return <div>Loading...</div> if (!isFeatureActive) return <div style={{ display: 'none' }}>Section is hidden</div> return ( <div> <Accordion> {movies.map( ({ movieName, moviePoster, movieProducer, reviewText }, index) => ( <AccordionItem key={index}> <AccordionItemTitle> <h3>{movieName}</h3> </AccordionItemTitle> <AccordionItemBody> <img src={`${apiUrl}${moviePoster}`} alt="" /> {!movieProducer ? null : ( <div>{`${movieProducer.name} ${ movieProducer.surname }`}</div> )} <div>{reviewText}</div> </AccordionItemBody> </AccordionItem> ) )} </Accordion> </div> ) } } export default App 

それだけです コンテンツマネージャーはレビューを簡単に管理できるようになり、機能の切り替えを使用して機能を有効または無効にすることもできます。

映画のレビューを表示するのは簡単な例です。詳細にdrれず、原則を示すためだけに意図的に引用しました。 実際には、機能は1桁以上複雑になる場合があります。 インターフェイス要素、製品カタログ、複雑なウィジェット、ランディングページ、フォームジェネレーター、投稿などがあります。また、この例では、cmsは情報のみを配布しますが、ほとんどのヘッドレスcmsはCRUD APIを提供します。一般的にエンティティを操作します。 一般に、ヘッドレスcmsのアイデアは、制御を任意のcmsに、また必要に応じて転送するために、任意の複雑なプロトコルを実装する自由と利便性を正確に提供することです。

選択基準と分析ヘッドレスCMS

ヘッドレスcmsを使用してどのタスクを解決するか、そしてその方法を理解した後、基準を選択し、システムの調査を開始しました。 headlesscms.orgによると、現在54 cmです。 それらのすべてを分析するのはかなり時間がかかるプロセスなので、最も人気があり注目される14のシステムを取り上げました：JSON CMS、Contentful、Strapi、GraphCMS、Squidex、Butter CMS、Cloud CMS、ockpit、Cosmic JS、Directus、Kentico Cloud、Netlify CMS 、プリズミック、ゴースト。

結果はテーブルの形で勉強するのにより便利です。 しかし、ここで複製します。

JSON CMS

充実した

ストラピ

GraphCMS

スクイデックス

バターcms

クラウドCMS

コックピット

宇宙のJS

Directus

Kentico Cloud

Netlify CMS

Prismic

Ghost

結論

概して、ヘッドレスcmsから、主に2つのことを期待していました：モデルを作成する自由、プロトコルを実装できるおかげで、すべての変更を透過的に管理できるように同様のバージョン管理システムをgitできます。
そして、ちょっとした失望が私を待っていました。これらのシステムのほとんどで作業できますが、私には不快な多くの不利な点があります。もちろん、これはシステムが悪いことを意味するのではなく、システムが私の期待を満たしていないことを意味するだけであり、私の期待が私の問題です。私はそれらを表明します：

• headless cms . , , . , , , , . , , . - Cloud CMS, Cockpit Cosmic JS.
• : , , . , - , — . , - , :
  

   { "oneOf": [ { "type": "number", "multipleOf": 5 }, { "type": "number", "multipleOf": 3 } ] } 

  
  Cockpit.
  
• , . , number, 100. , maximum: 50? ? GraphCMS.
• Git Cloud CMS Netlify CMS.

残念なことに、私がその公開会社で働いていたとき、これらのシステムを採用することはできませんでした。Cloud CMSは私たちのニーズに最も適していましたが、その価格はわずかです。

おわりに

そのため、この分析により、私は自分の頭のないcmを書く必要があると考えるようになりました。あなたはすでに彼女を見ました;彼女の例では、問題の解決策のデモンストレーションがありました。Any JSON CMSと呼ばれます。

更新：どのJSON CMSもオープンソースソリューションになりました。githubリポジトリはこちらです。

その主な目標は、任意の複雑なモデルを自由に作成し、gitのようなシステムを使用してすべての変更を制御することです。実装したいすべてのものからは程遠いもので、すでにメインの「メッセージ」があります。