ヘッドレスCMS。 なぜ私が書いているの

みなさんこんにちは！

この最近の記事は、私にこの出版物を書くよう促しました（昨日見ました）。

Headless / content-first / api-firstなどの主な機能をもう一度説明してください。 私はCMSではありません。素材は充実しており、おそらく多くの人がすでにこの傾向に精通しています。 そして、システムを作成する理由と方法、既存のシステムから選択できなかった理由、以前に遭遇した他のシステムについて考えていること、これらすべてについてどのような見通しがあるかについてお話したいと思います。 フィクションは膨大な量になりますが（2年間でこの資料について）、より面白く有用なものを書きます。 猫の下で誰が気にしてください。

一般的に、物語は本当に長く、私は最初にそれを話そうとします。 このエンジンを自分で作成する本当の理由をもっと明確にするため、または単にこれがないと、なぜ私がこのようにやっているのかを地上で説明するのが難しくなります。

しかし、初心者のために、それにもかかわらず、私は自分のために現代のヘッドレスCMSの主要な選択基準を簡単に書き留めます。 人々が多くのブナを読むために途切れず、最終的に何が伝えられるのか理解していないように。

要するに、私はすべてを1か所に置きたいと思っていました。背面と前面の両方（そして、どちらでもない）、GraphQL-API、そして「Make Beautiful」ボタンなど、データベースを管理することです。 これは見つかりませんでした。 私自身もまだこれをやっていませんが、全体としては非常に多くのことが判明しました。そして最も重要なことは、実際のプロジェクトを行うことができることです。

したがって、私のアプローチは科学的で正当化されるとはほとんど言えません。 事実、私は一般的に自分の何かを書くことが非常に多いです。 ここでプログラムするのが好きです。 そして2年前（そしてその8年前）に私はMODX CMFに座っていました（その下で多くの松葉杖も発明しました）。 そして3年間、かなり大規模なプロジェクトを開始しましたが、その下でMODXを使用できるように思えました。 しかし、結局のところ、私はできませんでした...主な理由は、技術的な要件のないスタートアップであり、毎日（そして1日に数回）変化し、補足される多くのアイデアがあったことです。 そして今、新しいアイデアの下で、新しいエンティティを追加し、既存のエンティティのフィールドを登録/変更し、これらのエンティティ間の関係を作成/削除/変更する必要があるたびに（それぞれ、データベース構造の変更に伴い）、ある時点でこれらのエンティティを変更するのに数時間かかりました。 実際、これらの変更をスキームに登録する必要があるという事実に加えて、データベースの変更（ほぼ手動）、APIの更新、プログラムコードの書き換えなどが必要でした。 したがって、このすべての下で前線を更新する必要がありました。 その結果、私は新しい、より便利なものを探す必要があると判断しました。 そのとき、私はphpバックエンドだったことをもう一度明確にします。そのため、さまざまなフロントエンドビルダー、少ないプロセッサ、npmなどを発見し始めたことに驚かないでください。 など しかし、とにかく、私たちのプロジェクトでは徐々に、react + less、GraphQLのAPI、およびexpressのサーバーに前線が現れました。

しかし、すべてが今のようにバラ色であるとは限りません。 これは2年以上前であることを思い出させてください。 最新のJS Webに2年未満しかアクセスしていない場合は、次の記事を読むことをお勧めします 。CreateReact アプリ （habr） を使用するN個の理由 。 簡単に言うと、反応スクリプトの出現により、webpackの構成などに煩わされることはありません。 これはすべてバックグラウンドに入ります。 親切な人はすでにwebpackを設定しているので、ほとんどの反応プロジェクトはほとんど動作することが保証されており、最終開発者は依存関係やローダーなどを設定するのではなく、最終製品のプログラミングに直接集中しています。 しかし、これは後です。 そしてその前に、私はこのウェブパックを設定し、追いつくために彼と一緒に飛んだすべての束の更新に従う必要がありました。 など しかし、これは作業の一部にすぎず、本質的には前線にすぎません。 また、サーバーも必要です。 また、APIも必要です。 また、SSR（サーバー側レンダリング）も必要です。私が知る限り、反応スクリプトはまだ提供していません。 一般に、すべては今よりもはるかに複雑で、それほど多くはありませんでした。 そして、どうやって私は松葉杖をつけましたか...

想像してみてください：

• フロントおよびサーバー用のネイティブwebpack構成。
• SSRの独自の実装。asyncがreact-serverで正常に動作し、スタイルがすぐに到着し、正常にインデックス付けされ、見つからないページのサーバーステータスが提供されます。
• ノーリデュース。 さて、私はすぐにreduxが好きではありませんでした。 私はネイティブの反応フラックスを使用するというアイデアが好きでした（ただし、自分で少し書き直さなければなりませんでしたが）。
• データベースを自動展開せずに、GraphQLスキームとリゾルバを手動で指定しました（APIサーバーはMODXサイトの中間として使用されました）。
• react-apollo / apollo-clientなどはありません すべては、カスタムフラックスに基づいて、ブラウザーでのフェッチ、リポジトリーを介した要求で個別に書き込まれます。

その結果、これまで、これの最初のバージョンの1つには、500人以上の出席者がいるプロジェクトがあり、シーズン（冬）には1日あたり1000〜1700人のユニークな学生がいます。 稼働時間2か月。 これは、予防的なソフトウェアの更新後にサーバーを手動で再起動したためです。 この再起動前には、稼働時間はさらに6か月以上でした。 しかし、最も興味深いのはメモリ消費です。 現在、ほぼ700メガバイトのjsプロセスがあります。 はい、はい、私もここであなたと笑っています:)もちろん、これはたくさんあります。 そしてその前に、私はもう少し予防し、この指標を改善しました。 以前は、プロセスごとに合計1000M +がありました...それにもかかわらず、それは機能し、かなり許容できました。 また、11月にGoogleがPageSpeed Insightsアルゴリズムを変更する前は、サイトのパフォーマンスメトリックは97/100でした。 証明

このプロジェクトなしでさらに開発されたシステムに基づいた、このプロジェクトに基づく中間結論（プロジェクトは取り残されました）：

長所

1. GraphQLを使用することでプロジェクトAPIがより柔軟になり、サーバーリクエストの数が大幅に削減されました。
2. プロジェクトは、npm上の膨大な数のコンポーネントにアクセスできます。
3. 依存関係やgitなどを使用することで、プロジェクト管理がより透明になりました。
4. 結果としてこの動物園から何を削除できるかわからない場合（そして、1つのサイトで複数のバージョンのバグを見ることは珍しくありません）、構築されたスクリプトとスタイルは、古いサイトの一連の個別のスクリプトよりも確かに楽しいです。
5. サイトはよりインタラクティブになり、ページは再起動せずに機能します。以前に表示したページに戻るためにサーバーを繰り返し呼び出す必要はありません。
6. データ編集は、ページ上で直接実行されます。「表示するものと表示するものを編集する」という原則に基づき、個別の管理パネルはありません。

短所（主に開発者向け）

1. すべてが非常に複雑です。 本当に。 一部のサードパーティ開発者のプロジェクトへの接続は、単純に非現実的です。 私はそれが何をどのように機能し、私の足がどこから成長するかをほとんど理解していなかった。 透明性について言及されているプラ​​スの3ページを見ると、透明性はどこかにフックすると、壊れているものをすぐに見ることができます（スクリプトは構築されません）が、コミットと差分によってあなたはそれが引っかかった場所を見つけることができます。 まあ、何か新しいものを追加することができ、それが機能する場合、少なくとも、はい、すべてがうまく飛んだことを明確に理解しています。 しかし、全体的にはまだ地獄のような地獄です。
2. キャッシングの難しさ。 その後、私は自分のためにアポロクライアントを発見しました。 そしてその前に、私が言ったように、フラックスベースのストレージを書きました。 これらのストレージにより、さまざまなコンポーネントからレンダリングに必要なデータを取得できましたが、クライアント側のキャッシュサイズは非常に大きかった（エンティティの各セットには独自のリポジトリがありました）。 その結果、オブジェクトが以前にリクエストされたかどうか（つまり、それを見つけるためにサーバーにリクエストする価値があるかどうか）、関連するすべてのデータが利用可能かどうかなどを検証することは困難でした。
3. スキーマ、データベース構造、リゾルバの問題（データを受信/変更するためのAPI機能）。 私が言ったように、私は手動で回路を書き、リゾルバも書きました。 リゾルバで何をするかで、キャッシュを提供し、ネストされたリクエストやその他の微妙な処理を提供しようとしました。 その瞬間、私は本質とGraphQLプログラムコードに深く入り込まなければなりませんでした。 利点は、GraphQLの仕組み、その長所と短所、およびそれをよりよく調理する方法を一般的によく理解していることです。 欠点は、もちろん、アポロのようなコマンドで書かれたアメニティやバンをすべて1つに書くことができないことです。 その結果、私がアポロを発見したとき、もちろん、私はそれらのコンポーネントを非常に喜んで使い始めました（しかし、主に前面で、以下にその理由を説明します）。

一般的に、時代遅れのテクノロジーを使用するこのプロジェクトは、個人的には100％のものであるため、より良い時期までそれを放棄する余裕があります。 しかし、さらに進んでプラットフォームを開発する必要があった他のプロジェクトがあります。 そして数回、すべてをゼロから書き直さなければなりませんでした。 さらに、遭遇した個々のタスクと、その結果として開発および適用したソリューションについて詳しく説明します。

スキーマファースト。 最初に回路、次に他のすべて

サイト（Webインターフェイス、シンクライアントなど）はすべて情報の表示です（許可されている場合は情報管理、および許可されている場合は機能が許可されます）。 しかし、最初に、すべて同じ、データベース（テーブル、列など）。 途中でデータベースを操作するためのいくつかの異なるアプローチに遭遇したので、私はスキーマファーストのアプローチが最も好きでした。 つまり、エンティティとデータ型のスキーマを（手動またはインターフェイスを介して）記述し、スキーマを展開し、記述された変更をデータベースにすぐに適用します（テーブル/列が作成/削除され、それらの間の関係も）。 実装に応じて、このデータを管理するために必要なすべてのリゾルバー関数も生成します。 何よりもこの方向で、私はprisma.ioプロジェクトが好きでした。

あなたの許可を得て、私はハブについてもプリズムについての記事を見たことがないので、私は彼らに少し注意を引きます。プロジェクトは本当に非常に興味深いからです。そして、彼らなしでは、私をそんなに喜ばせるようなプラットフォームはありません。 実際、prisma.ioが非常に大きな役割を果たしているため、プラットフォームをprisma-cmsと呼んでいます。

実際、prisma.ioはSaaSプロジェクトですが、大きな警告があります。彼らは、行うことのほとんどすべてをgithubに配置します。 つまり、非常にリーズナブルな料金でサーバーを使用する（数分で独自のデータベースとAPIを構成する）ことも、自宅ですべてを完全に展開することもできます。 この場合、プリズムは論理的に2つの重要な別個の部分に分割する必要があります。

1. Prisma-server、つまりデータベースも回転しているサーバー。
2. プリズマクライアント。 基本的にはサーバーでもありますが、データソース（prisma-server）に関してはクライアントです。

次に、この紛らわしい状況について説明します。 一般に、プリズムの本質は、単一のAPIエンドポイントを使用して、さまざまなデータソースを操作できることです。 はい、ここでは誰もがGraphQLを思いついたと言うでしょう。prismaはここでは必要ありません。 一般的に、誰もが正しいでしょうが、重大なポイントがあります：GraphQLは原則と全体的な作業のみを定義しますが、それ自体では最終的なデータソースを使用した作業を提供しません。 彼は、「ユーザーが送信できるリクエストを記述するAPIを作成できますが、これらのリクエストをどのように処理するかはユーザーが決める必要があります。」 そしてもちろん、プリズムもGraphQLを使用します（ちなみに、さまざまなアポロ製品を含む他の多くのもの）。 しかし、これに加えてプリズムは、データベースでの作業を提供するだけです。 つまり、スキームとそのデプロイメントについて説明すると、必要なテーブルと列（およびそれらの間の関係）が指定されたデータベースにすぐに作成され、必要なすべてのCRUD関数もすぐに生成されます。 つまり、プリズムを使用すると、GraphQLサーバーだけでなく、すぐにデータベースを操作できる完全に機能するAPIを取得できます。 したがって、Prisma-serverはデータベースとデータベースとの相互作用を提供し、prisma-clientを使用すると、リゾルバーを記述し、prisma-server（またはいくつかのprisma-サーバーでも）にリクエストを送信できます。 したがって、prisma-clientは自分でしかデプロイできない（そしてSaaS prisma.ioがprisma-serverとして使用される）ことができ、prisma-serverを自分でデプロイでき、通常はプリズムにまったく依存せず、それがすべてですあなたのもの。

ここでは、プラットフォームの基礎として、プリズムを自分用に選択しました。 しかし、それから完全なプラットフォームを得るために自分でそれをスピンしなければなりませんでした。

1.スキームのマージ

当時、プリズムは回路を組み合わせることができませんでした。 つまり、タスクは次のとおりです。

1つのモジュールに記述されたユーザーモデルがある

type User { id: ID! @unique username: String! @unique email: String @unique } 

そして別のモジュールで

 type User { id: ID! @unique username: String! @unique firstname: String lastname: String } 

1つのプロジェクトの一部として、これら2つのスキームを自動的に組み合わせて出力を取得します。

 type User { id: ID! @unique username: String! @unique email: String @unique firstname: String lastname: String } 

しかし、その後、このプリズムはできませんでした。 merge-graphql-schemasライブラリを使用してこれを実装することが判明しました。

任意のプリズムサーバーで動作します。

プリズムでは、構成は特別な構成ファイルに書き込まれます。 使用されているプリズムサーバーのアドレスを変更する場合は、ファイルを編集する必要があります。 些細なことで、快適ではありません。 たとえば、endpoint = http：// endpoint-address yarn deploy（yarn start）のように、コマンドでURLを指定できるようにしました。 これは数日間殺されました...しかし、今では、1つのプリズムプロジェクトを任意の数のエンドポイントに使用できます。 ところで、prisma-cmsはローカルデータベースでも、SaaSプリズムサーバーでも簡単に機能します。

モジュール/プラグイン

これは一般に十分ではありませんでした。 私が言ったように、プリズムの主なタスクは、さまざまなデータベースで作業を提供することです。 そして、彼らはこれについて素晴らしい仕事をしています。 既に、MySQL、PostgreSQL、Amazon RDS、MongoDB、さらにいくつかの種類のソースの使用をサポートしています。 ただし、モジュール式インフラストラクチャは提供しません。 これまでのところ、市場などはありません。 典型的なブランクはごくわずかです。 ただし、複数のブランクから2つまたは3つを選択して、1つのプロジェクトにインストールすることはできません。 いずれかを選択する必要があります。 最終プロジェクトに異なる数のモジュールをインストールできるようにし、回路とリゾルバーを展開するときに、機能をすべて備えたこのような単一のプロジェクトが楽しくなるようにしたかったのです。 また、グラフィカルインターフェイスはまだありませんが、最終プロジェクトで組み合わせることができる20以上の作業モジュールとコンポーネントが既にあります。 ここで個人的な定義について少し決定します。モジュールは背面にインストールされるもの（データベースとAPIを拡張する）であり、コンポーネントは前面にインストールされるもの（さまざまなインターフェース要素を追加するため）です。 これまでのところ、モジュールを接続するためのグラフィカルインターフェイスはありませんが、この方法で書くことは難しくありません（これはよく行われません）。

  constructor(options = {}) { super(options); this.mergeModules([ LogModule, MailModule, UploadModule, SocietyModule, EthereumModule, WebrtcModule, UserModule, RouterModule, ]); } 

新しいモジュールを追加した後、単に1つのコマンドでデプロイを実行するだけで十分です。ここでは、新しいテーブル/列と拡張機能が既にあります。

5バックエンドの変更に対応するフロント

これはまったく十分ではありませんでした。 これに余談があります。 実際のところ、私が見たすべてのAPIファーストCMSは、「APIを提供するのは素晴らしいことであり、あなたは最前線に望むものを台無しにしてしまう」ということです。 これは彼らの「あなたが望むものは何でもねじ」であり、実際、「あなたが望むように仲間」を意味します。 UIフレームワークが言うのとまったく同じで、「クールなボタンを見て、それをすべて実行し、自分自身でバックエンドと混同します」と言います。 それは常に殺された。 GraphQLを使用し、前後の両方を提供する、javascriptで記述された包括的なCMSを見つけたいだけです。 しかし、私はそのようなものを見つけませんでした。 APIの変更がすぐにフロントで認識されるようにしたかったのです。 このため、いくつかのサブステップが完了しました。

5.1 APIフラグメントの生成

前面では、スキーマファイルのフラグメントがリクエストに登録されます。 サーバー上でAPIが再構築されると、APIフラグメントを含む新しいJSファイルも生成されます。 そして、リクエストでは次のように書かれています：

 const { UserNoNestingFragment, EthAccountNoNestingFragment, NotificationTypeNoNestingFragment, BatchPayloadNoNestingFragment, } = queryFragments; const userFragment = ` fragment user on User { ...UserNoNesting EthAccounts{ ...EthAccountNoNesting } NotificationTypes{ ...NotificationTypeNoNesting } } ${UserNoNestingFragment} ${EthAccountNoNestingFragment} ${NotificationTypeNoNestingFragment} `; const usersConnection = ` query usersConnection ( $where: UserWhereInput $orderBy: UserOrderByInput $skip: Int $after: String $before: String $first: Int $last: Int ){ objectsConnection: usersConnection ( where: $where orderBy: $orderBy skip: $skip after: $after before: $before first: $first last: $last ){ aggregate{ count } edges{ node{ ...user } } } } ${userFragment} `; 

5.2すべてのコンポーネントに1つのコンテキスト

React 16.3では、 新しいコンテキストAPIが導入されています 。 任意のレベルの子コンポーネントで、コンテキストから事前に必要なタイプをリストせずに単一のコンテキストにアクセスできるようにしましたが、単に静的contextType = PrismaCmsContextを指定し、this->コンテキスト（APIクライアント、スキームを含む） 、リクエストなど）。

5.3動的フィルター

私も本当にやりたかった。 GraphQLを使用すると、ネストされた構造を持つ複雑なクエリを作成できます。 フィルターも動的で、APIスキームから形成され、ネストされた条件を作成できるようにしたかったのです。 起こったことは次のとおりです。

5.4ウェブサイトビルダー

そして最後に、私が欠けていたのは外部サイト編集者、つまりデザイナーでした。 サーバー上で最小限のアクションのみを実行したかったため、最終的な設計はすべてフロントで行う必要があります（ルーティングの設定、選択の生成など）。 これは別の記事のトピックです。何よりも、純粋なcontentEditableで、私はそれのために私のwrutch wysiwygエディターも書いたので、多くの微妙な点があります。 自分の権利が回復し、興味のある人がいる場合は、別の記事を書きます。

さて、最後に、動作中のデザイナーの短いデモビデオ。 まだ生ですが、私はそれが好きです。


それが終わるまで。 書きたいことはまだ書いていませんが、たくさんのことが起こりました。 コメントさせていただきます。

PS：サイト自体のソースコードを含むすべてのソースコードはこちらです。