Decoupled CMS考 - DrupalとWordPressから見る次世代のCMSフロントエンド

なぜフロントエンドとバックエンドを分離するのか？

Decoupled（分離した）構成についての話をする前に、なぜこのような構成が提唱されるようになったかを考えます。

DrupalやWordPress、concrete5などのCMSは非常に優れたフロントエンドを構築するシステムを備えています。そのため、サイト管理者はコーディングの知識をほとんど必要とすることなく、またサードパーティのエクステンション（テーマ・モジュール・WordPressプラグインなど）を用いることで自由にサイトを拡張することができました。

しかし一方でこの自由さが問題となっている場所も存在します。それはサーバーです。 DrupalなどのCMSがインストールされているサーバーは、非常に沢山のタスクを請け負っています。入稿されたコンテンツをデータベースに保存すること。SQLで照会された内容に該当するコンテンツをデータベースから探し出すこと。テンプレートにコンテンツをはめ込み、HTMLを作成すること。などなど。この他にもユーザー管理や各種モジュールによって追加されたタスクなどもこなす必要がありますので、私たちの見えないところでCMSはとてもハードな仕事をしているといえるでしょう。

そしてコンテンツの更新が容易にできるようになったことから、ウェブサイトが盛んに更新され、それによってアクセスが次第に増加してきます。すると先ほど述べたようなCMSが請け負うタスクの量はどんどん増加し、最後にはサーバーの処理能力を超えたことによるサーバーエラーが発生します。より多くのユーザーに来てもらうために導入したCMSが、その導入の成果によってユーザーがアクセスできなくなる状況を発生させてしまうというなんともはがゆい結末ですね。

ではこの問題を解決するにはどうすればよいでしょうか？人間と会社で置き換えて考えると、もっとも良い判断は「任せているタスクを減らすこと」でしょう。CMSのインストールされているサーバーが請け負うタスクの量を何かしらの形で減らしてやれば、より多くのユーザーが訪問しても問題なくなります。そこで出てくるのがDecoupled構成です。

API駆動となるDecoupled構成

Decoupled構成では、CMSはAPIエンドポイント＋記事入稿システムとして振舞うことになります。コンテンツの入稿などの管理画面タスクはそのままに、フロントエンドの描画についてを別のサーバーに委譲するというスタイルです。

DrupalやWordPressはREST APIエンドポイントを作ることが比較的容易であるため、フロントエンドの実装をこれらの外で行い、CMSはあくまでコンテンツを生成・管理する部分に専念するという形となります。

またこのDecoupled構成をより突き詰めた形として、「The Twelve-Factor App」という概念もあります。こちらもよりスケーラブルでセキュアなアプリケーションを作るための方法論として詳しくまとめられていますのでぜひご覧ください。

なぜフロントエンドを分離するのか？

実はDecoupled（分離した）構成には他のパターンも存在します。たとえばデータベースサーバーを別途用意し、データの管理を委譲する形。またはCDNを用意することで、コンテンツの配信部分を委譲し、サーバーへの負荷を減らすという形もあります。この他にも様々なパターンが存在し、実はこれらの方が現時点ではメジャーな解決策です。

ではなぜわざわざCMSの持つテーマ・テンプレート機能を捨てて、フロントエンドを分離するのでしょうか？これにはさまざまな理由がありますが、大きな理由の１つとしてProgressive Web Applicationの存在があります。Progressive Web Application(PWA)はGoogleが提唱する新しいアプリケーションの形で、ウェブサイトとアプリケーションの両方の利点を兼ね備えたアプリケーションのことをさします。

App Shellモデルに基づいてアプリケーションのようにウェブサイトを構築することになり、オフラインやネットワークの不安定な環境でもサイトが閲覧でき、アプリケーションのように振舞いつつもURLを持つためにGoogleなどの検索エンジンからも見つけてもらいやすくなります。

このPWAを既存のCMSのテーマやモジュールに組み込む事も不可能ではありません。しかし「アプリケーションのようなウェブサイトを作る」というコンセプトを踏まえるとやはりAngularやReact / Vue.jsなどで構築するSingle Page Applciation(SPA)として構築することがベストでしょう。

WordPressでのDecoupled構成

では実際にDecoupled構成のウェブサイトを作るにはどうすればよいでしょうか？ WordPressの場合では、WP API (WP REST API)を用いて実装する形が現在ではスタンダートです。

WordPressコアにプリインストールされているBackbone.jsクライアントを用いる方法もありますが、こちらはWordPressテーマとして作ることになるためDecoupled構成ではない形となります。現在一般的な方法は、node-wpapiというWP APIの開発にも参加しているエンジニアが公開しているクライアントライブラリをnpmでインストールし、そちらを用いてWordPressのデータを取得するという方法です。

ustwoのようにフロントエンドの構成をOSS化している会社もあり、注目度は低くないと言えるでしょう。

Drupal + Decoupled構成のメリットとは？

ではDrupalではどうでしょうか？WordPressの長所はブログのようなコンテンツを更新することに最適化されていることです。そのため事前に設定したルールで各ページのパーマリンクを自動的に生成することや、タイトル＋本文という形での執筆に最適化されたエディタが用意されています。

しかし一方でWordPressに「コンテンツ」ではなく「データ」を保存しようとすると少し難易度があがります。データベースの構造上、「記事に対するメタデータ」という形で各種データを保存するため、SQLでの検索の難易度があがるなどのデメリットがあります。

反対にDrupalはデータの保存に対して強みがあり、コア機能だけでもフィールドの追加や検索APIの追加が比較的簡単に行うことができます。また、Drupal8には現時点では未対応ですがDKANを用いることでオープンデータの配信も可能になるという点も長所だといえるでしょう。

カタログデータやナレッジベース、行政や会社情報といったデータが中心になるウェブサイトはDrupalにホストし、ニュースやメディアなどのコンテンツが中心になるウェブサイトはWordPressでホストする。このようなCMSレベルでDecoupledとなる運用も将来的には増えてくるかもしれません。そしてフロントエンドをDecoupledにすることで、Drupalがホストする「データ」とWordPressがホストする「コンテンツ」をマッシュアップした企画やコンテンツを配信することも将来的に可能になるでしょう。

Decoupledにするデメリット

もちろんメリットだけではなく、デメリットもあります。「CMSが提供するエコシステムを利用できなくなる」という点が目立つデメリットとして挙げられます。

例えばフロントエンドをDecoupledにした場合、CMSが提供するテーマ・テンプレートエンジンとREST API以外のAPIがほぼ利用できなくなり、表示に関する実装をほぼ自前で作る必要が生じます。一方でエディタをDecoupledにした場合、執筆に関わるプラグイン・エクステンションが利用できなくなるケースなどが考えられます。

そしてなにより大きな問題として、「そのCMS」と「Decoupledにしたアプリケーション」の２つを管理する必要が生まれるという点があります。

この点については、以下の記事などもあわせてご覧ください。

• Decoupled Drupalとは何か？なぜ重要なのか？:
  https://annai.co.jp/article/decoupled-drupal
• 第14回 Drupalのテーマシステムについて：
  https://annai.co.jp/drupal/beginner/themging

CMSのContentとはなにか

このように現在フロントエンドではあえてCMSのHTML生成機能を使わずにAPIとして利用するケースが増えて来ています。そのため、CMS(Contents Management System)のCについて再定義する必要が出て来ているかもしれません。

これまでは「Contents = DBのデータをHTMLに描画したもの」でしたが、DecoupledなCMSにおいては「Contens = DBのデータをJSONにまとめたもの」という扱いです。

「The Twelve-Factor App」で紹介されているアプリケーションのように、それぞれのアプリケーション・システムがより成果を出せるように役割分担をしっかりと行なっていく。そのような運用の形がデファクトになるのもそう遠くない未来かもしれません。