近年ユーザーが閲覧するフロントエンドと、管理者・ライターがコンテンツを管理するバックエンドを分離したアーキテクトでウェブサイトを構築する事例が増えてきています。今回はこのフロントエンドとバックエンドを分離した形で構築するウェブサイトについて、DrupalとWordPressのそれぞれの特徴などを考えてみましょう。フロントエンドとバックエンドを分離するのか?Decoupled(分離した)構成についての話をする前に、なぜこのような構成が提唱されるようになったかを考えます。DrupalやWordPress、concrete5などのCMSは非常に優れたフロントエンドを構築するシステムを備えています。そのため、サイト管理者はコーディングの知識をほとんど必要とすることなく、またサードパーティのエクステンション(テーマ・モジュール・WordPressプラグインなど)を用いることで自由にサイトを拡張することができました。一方でこの自由さが問題となっている場所も存在します。DrupalなどのCMSがインストールされているサーバーは、非常に沢山のタスクを請け負っています。入稿されたコンテンツをデータベースに保存すること。SQLで照会された内容に該当するコンテンツをデータベースから探し出すこと。テンプレートにコンテンツをはめ込み、HTMLを作成すること。この他にもユーザー管理や各種モジュールによって追加されたタスクなどもこなす必要がありますので、私たちの見えないところでCMSはとてもハードな仕事をしているといえるでしょう。コンテンツの更新が容易にできるようになったことから、ウェブサイトが盛んに更新され、それによってアクセスが次第に増加してきます。すると先ほど述べたようなCMSが請け負うタスクの量はどんどん増加し、最後にはサーバーの処理能力を超えたことによるサーバーエラーが発生します。多くのユーザーに来てもらうために導入したCMSが、その導入の成果によってユーザーがアクセスできなくなる状況を発生させてしまうというなんともはがゆい結末ですね。この問題を解決するにはどうすればよいでしょうか?人間と会社で置き換えて考えると、もっとも良い判断は「任せているタスクを減らすこと」でしょう。CMSのインストールされているサーバーが請け負うタスクの量を何かしらの形で減らしてやれば、より多くのユーザーが訪問しても問題なくなります。そこで出てくるのがDecoupled構成です。API駆動となるDecoupled構成Decoupled構成では、CMSはAPIエンドポイント+記事入稿システムとして振舞うことになります。コンテンツの入稿などの管理画面タスクはそのままに、フロントエンドの描画についてを別のサーバーに委譲するというスタイルです。APIエンドポイントを作ることが比較的容易であるため、フロントエンドの実装をこれらの外で行い、CMSはあくまでコンテンツを生成・管理する部分に専念するという形となります。App」という概念もあります。こちらもよりスケーラブルでセキュアなアプリケーションを作るための方法論として詳しくまとめられていますのでぜひご覧ください。フロントエンドを分離するのか?実はDecoupled(分離した)構成には他のパターンも存在します。データベースサーバーを別途用意し、データの管理を委譲する形。CDNを用意することで、コンテンツの配信部分を委譲し、サーバーへの負荷を減らすという形もあります。この他にも様々なパターンが存在し、実はこれらの方が現時点ではメジャーな解決策です。Applicationの存在があります。Application(PWA)はGoogleが提唱する新しいアプリケーションの形で、ウェブサイトとアプリケーションの両方の利点を兼ね備えたアプリケーションのことをさします。Shellモデルに基づいてアプリケーションのようにウェブサイトを構築することになり、オフラインやネットワークの不安定な環境でもサイトが閲覧でき、アプリケーションのように振舞いつつもURLを持つためにGoogleなどの検索エンジンからも見つけてもらいやすくなります。このPWAを既存のCMSのテーマやモジュールに組み込む事も不可能ではありません。Applciation(SPA)として構築することがベストでしょう。API)を用いて実装する形が現在ではスタンダートです。WordPressコアにプリインストールされているBackbone.jsクライアントを用いる方法もありますが、こちらはWordPressテーマとして作ることになるためDecoupled構成ではない形となります。APIの開発にも参加しているエンジニアが公開しているクライアントライブラリをnpmでインストールし、そちらを用いてWordPressのデータを取得するという方法です。ustwoのようにフロントエンドの構成をOSS化している会社もあり、注目度は低くないと言えるでしょう。Decoupled構成のメリットとは?ではDrupalではどうでしょうか?WordPressの長所はブログのようなコンテンツを更新することに最適化されていることです。そのため事前に設定したルールで各ページのパーマリンクを自動的に生成することや、タイトル+本文という形での執筆に最適化されたエディタが用意されています。一方でWordPressに「コンテンツ」ではなく「データ」を保存しようとすると少し難易度があがります。データベースの構造上、「記事に対するメタデータ」という形で各種データを保存するため、SQLでの検索の難易度があがるなどのデメリットがあります。反対にDrupalはデータの保存に対して強みがあり、コア機能だけでもフィールドの追加や検索APIの追加が比較的簡単に行うことができます。Drupal8には現時点では未対応ですがDKANを用いることでオープンデータの配信も可能になるという点も長所だといえるでしょう。カタログデータやナレッジベース、行政や会社情報といったデータが中心になるウェブサイトはDrupalにホストし、ニュースやメディアなどのコンテンツが中心になるウェブサイトはWordPressでホストする。このようなCMSレベルでDecoupledとなる運用も将来的には増えてくるかもしれません。フロントエンドをDecoupledにすることで、Drupalがホストする「データ」とWordPressがホストする「コンテンツ」をマッシュアップした企画やコンテンツを配信することも将来的に可能になるでしょう。Decoupledにするデメリットもちろんメリットだけではなく、デメリットもあります。「CMSが提供するエコシステムを利用できなくなる」という点が目立つデメリットとして挙げられます。API以外のAPIがほぼ利用できなくなり、表示に関する実装をほぼ自前で作る必要が生じます。一方でエディタをDecoupledにした場合、執筆に関わるプラグイン・エクステンションが利用できなくなるケースなどが考えられます。なにより大きな問題として、「そのCMS」と「Decoupledにしたアプリケーション」の2つを管理する必要が生まれるという点があります。この点については、以下の記事などもあわせてご覧ください。Drupalのテーマシステムについて:https://annai.co.jp/drupal/beginner/themgingCMSのContentとはなにかこのように現在フロントエンドではあえてCMSのHTML生成機能を使わずにAPIとして利用するケースが増えて来ています。System)のCについて再定義する必要が出て来ているかもしれません。DBのデータをJSONにまとめたもの」という扱いです。App」で紹介されているアプリケーションのように、それぞれのアプリケーション・システムがより成果を出せるように役割分担をしっかりと行なっていく。そのような運用の形がデファクトになるのもそう遠くない未来かもしれません。AoyamaANNAI株式会社の出社しないCTO。昔は回線交換やL2/L3のプロトコルスタックの開発をしてました。RailsなどのWebシステム開発などを経て現職。インフラからDrupalのモジュール開発、Drupal以外の開発までなんでもやります。普段は札幌で猫と一緒にリモートワークしています。7(47)イベント(22)マーケティング(11)セキュリティ(38)Webガバナンス(5)リモートワーク(10)ANNAIカルチャー(22)Drupal(136)ドゥルーパル(110)ドルーパル(110)ウェブサイトに関することならお気軽にご相談くださいお問い合わせお見積のご依頼や詳しい内容のご相談、取材などに関することはお問い合わせをご利用ください。