オープンソース・ソフト Drupal を使った Web サイトの構築・サポート・研修

2018 年版 Drupal のデカップリング方法

この記事は「Drupal をいつ、どうやってデカップリング(分離)するか」という手引きにしてみたい。

2 年ほど前、僕は「How should you decouple Drupal?(Drupal をどう分離すべきか?)」というブログ記事を書いた。その記事にあったフローチャートは、たくさんの人が自分の Drupal 設計に取り組む意思決定に役立った。そのときから、Drupal もコミュニティーも、それらを取り巻く市場も進化してきたので、元のフローチャートを大きく更新する必要が出てきた。

Drupal の「API ファースト」イニシアチブは新しい性能(機能)を導入した。そして、Waterwheel エコシステム、それから、ReservoirHeadless LightningContenta といった API ファースト ディストリビューションが登場してきた。Drupal コミュニティーの内外で、Node.js を試し、完全にデカップリングされたアーキテクチャーを採用する開発者も増えている。そういったことの結果として、Acquia は Node.js ホスティングを提供するようになった。これは、Acquia プラットフォーム上で分離型 Drupal を実装するのが、これまでになく容易になったことを意味する。

まず、新しいフローチャートの全体像から始めよう:

フローチャート「Drupal の分離方法」

Drupal を分離するすべての方法

「カップリングされた(coupled)Drupal」とも呼ばれる、Drupal アーキテクチャーにおける従来のアプローチは、一枚岩型(monolithic)の実装だ。この場合、Drupal はフロントエンドとバックエンド、すべての事柄に対するコントロールを保持する。これは僕たちが元々、「Drupal」として理解していたものだ。従来型の Web サイトには理想的。コンテンツ制作者が使うのなら、このカップリング状態の Drupal を保つのが最適なアプローチだ。フロントエンド開発者にあまり頼ることなく市場に素早く公開したいときなどには特にそれが当てはまる。また、Drupal 8 が大好きで、その構成全体を保持しておきたい開発者にとっても、従来型の Drupal はすばらしいアプローチであり続ける。

2 番目のアプローチとしては、プログレッシブにデカップルされた Drupal が挙げられる。これは、レイアウト管理などの「編集上のニーズ」と、Drupal のフロントエンドに JavaScript フレームワークを挿入してもっと JavaScript を使いたいという「開発者の願望」との帳尻を合わせるものだ。ページの「入れ物」だけを Drupal がレンダリングして最初からあるデータを入れておくにしても、ページ内のきっちりと指定されたセクションだけを JavaScript がコントロールするにしても、プログレッシブなデカップリングは実際のところ、ひとつの連続領域だ(ひとつひとつのデカップリング方法の間に境界線があるわけではなく、デカップリングのレベルが隣り合ってつながっている)。プログレッシブに分離された Drupal は世界を虜(とりこ)にしたわけではない。その理由はおそらく、それが JavaScript と PHP の両方をミックスしたものであって、Node.js 経由でサーバーサイドのレンダリングを利用するわけではないからだろう。それにしても、それは、より妥協することで編集者と開発者の両方にとって重要な機能を提供してくれるわけだから、魅力的なアプローチだ。

話の順序としては最後になったが、ここ数年、JavaScript の勢いが全く衰える気配もなく伸び続けるにつれて、完全にデカップルされた Drupal がいっそう注目されてきている。これはコンテンツの構造と、そのコンテンツの出し方に関する事柄を完全に分離するものだ。端的にいえば、Web 体験とは単なる別のアプリケーションであって、そこにコンテンツを渡す必要がある、とみなすわけだ。その結果、インプレース編集やコンテンツのプレビューなど、標準で備わっている CMS 機能を失うことになるが、それでも人気があるのは、フロントエンド開発者がそれだけの自由とコントロールを得るからだ。

構築しようとしているものは何か?

「Drupal の分離方法」フローチャート(上部のみ)

いちばん重要な質問は「何を構築しようとしているのか」だ。

  1. スタンドアローンの Web サイトまたは Web アプリケーションをひとつ作る計画なら、Drupal を分離することが正しいかどうかは、開発者や編集者が求める必須機能によって決まる。
  2. 複数の体験(Web、ネイティブ モバイル、IoT など)を作る計画なら、Drupal を使って Web サービス API を提供し、他の体験にコンテンツを配信できる。それは (a) 外部に面したコンポーネントのないコンテンツ リポジトリーとして、または (b) コンテンツ リポジトリーでもある従来型の Web サイトとしてだ。

分離型の Drupal が自分のユース ケースにとって役立つかどうかを最終的に決めるのは自分のニーズだ。編集機能が必要なスタンドアローンの Web サイトを作るのなら技術的に見て分離する理由はない。ただ、それは「PHP よりも JavaScript の方が好きだからデカップリングする人」がいないという意味ではない。それでも、分離型アプローチをとる場合は編集者のニーズによく注意して、重要な機能が取り除かれてしまうことが決してないようにする必要がある。逆に、Drupal を IoT またはネイティブ アプリケーション用のコンテンツ リポジトリーとして使う場合は、デカップリングは避けられない。次の部分のフローチャートは、これらのトレードオフ(交換条件)を比較検討するのに役立つだろう。

今日、Drupal では、分離型の Drupal を利用するアプリケーションをずっと簡単に作れるようになった。他のアプリケーションにコンテンツを配信するためのコンテンツ リポジトリーとして Drupal を使う場合であっても、JSON APIGraphQLOpenAPICouchDB といった広く知られている仕様は習得にかかる労力を大きく減らしてくれる。また、そうした標準規格を作ったコミュニティーによって提供されているツール利用のエコシステムへの扉も開いてくれる。それに加えて、今では、コンテンツ リポジトリーとしての利用に最適化された「API ファースト」ディストリビューションや Waterwheel.js のような SDK があり、開発者が「Drupal 語を話せる」ようにもなっている。

なくてはならないものがあるか?

「Drupal の分離方法」フローチャート(中間部分)

Drupal をデカップリングする決定で、どんな場合でも、おそらく、いちばん肝心なのは編集者と開発者の両方に求められる必須機能群だろう。分離した Drupal を使うべきかどうかを決めるには、編集者と開発者にとってどの機能がいちばん貴重なのかを切り分けることが大事だ。あいにく、その際、「白か黒か」に分かれる回答はない。どのプロジェクトにおいても、プラス点とマイナス点を天秤にかけて検討しなくてはならないものだ。

たとえば、多くのマーケティング チームが CMS を選択するのは、彼らがいくつものランディング ページを作りたいからであり、 ページ上でコンテンツをレイアウトし、ページをすばやく再構成する機能が CMS に備わっているからだ。開発者に助けてもらわなくてもそういったことをすべて実現できること。それは、マーケターから見れば CMS そのものの是非にかかわる。同様に、多くのデジタル マーケターが評価するオプションとして、プレビュー内でのコンテンツ編集と、その編集をさまざまな(承認)ワークフロー段階で行うことがある。完全にデカップリングされた構成では、Drupal にはフロントエンドに対するコントロールがないので、こうした機能は通常、失われてしまう。

その一方で、微妙なインタラクションを作り込みたかったり、作りたい UX(の具体イメージ)が決まっていたりする場合、コンテンツのビジュアルな出し方をコントロールするニーズは開発者の邪魔になり得る。さらに言うなら、開発者チームは最新最高のテクノロジーを使いたがることが多く、JavaScript もその例外ではない。今日日、サーバーサイドのレンダリングや ES6 トランスパイレーションといったモダンなテクニックを自分の「道具箱」に携えている JavaScript 開発者が増えている。(組織の)意思決定者はそのことも考慮するべきだ。

開発者のニーズと編集者の要求の狭間にある、この緊張をどう解くか。選択するアプローチはその点で決まる。完全に編集する側にフォーカスしていて開発系人材がいないチーム、あるいはコンテンツの編集、配置およびコンテクスト内でプレビューする機能に対するニーズが大きいチームがあるとする。その場合、Drupal をデカップルすると、編集者がこうしたビジュアルな変更操作を行えるようにするための Drupal 内部の重要な連結関係が取り払われてしまうことになる。しかし、もっともっと柔軟に対応したいと考え、とりたてて編集者やマーケッターの要望に応じる必要もない開発チームなら、完全に分離した Drupal の方が自由を与えてくれるだろうし、業界の新しいパラダイム(規範)を探ってみることもできるだろう。ただ、その場合、編集者にとって大事な機能の多くは利用できなくなるという但し書きが付くということだ。

未来はどうなる?

デカップル型の Drupal が急速に進化していることもあり、僕は Drupal が将来、開発者と編集者の隔たりをどんどん縮めていってくれたらと望んでいる。結局のところ、それは CMS というものが当初、目指していたゴールなのだから。すなわち、コンテンツ作者がコンテンツを書いて自分の Web サイトを組み立てるようにするということだ。Drupal の歴史はいつも、編集上のニーズと開発者のニーズとのバランスをとることだった。それは、Drupal が駆動する体験(ユーザー体験など)の数が増大したところで変わらない。

今の Drupal で Web サイトを管理するのと同じくらい容易に、マーケッターが、現在の、そして今後、登場してくる、その他のチャネルすべてを管理できるようにする必要がある。(僕たちにとって)次の大きなハードルは、それをどういう風に始めるか、だと思う。未来を描くとしたら、コンテンツ作者としては、1つのコンテンツ モデルを作り、すべてのチャネルでコンテンツをプレビューし、使い慣れたツールで編集し、コンテンツを配置できるのが理想だ。それも、そのチャネルが、モバイル、チャットボット、デジタル サイネージであろうと、AR(拡張現実)であろうともだ。

今日、開発者は、自分のさまざまなアプリ用の単なるコンテンツ置き場としてではなく、独自にあつらえた編集用インターフェイスを作成する手段としても Drupal を使うようになってきている。だから僕としては、新しい編集用インターフェイスの構想を練るための実験がもっと出てくることを望んでいる。それは、増え続けているチャネルをコントロールしたいというニーズを抱えるコンテンツ作者たちに、そのコントロールを与えるインターフェイスだ。その時点で僕たちはきっと新しいフローチャートが必要になるだろう。

結論

ありがたいことに、Drupal はちょうどいい時期にちょうどいい所にいる。僕たちは、Drupal 8 の Web サービスとそれまでの拡張モジュールを利用した分離(デカップルド)CMS アーキテクチャーという新しい世界を予見した。そして、もっと最近になってくると、いくつもの API ファースト ディストリビューションや SDK、さらには Ember や React には「リファレンス(基準、定番)」とされるアプリまで出てきた。ツールが揃って、Drupal という名前も聞いたことがなかった開発者でも、かつてないほどいろいろな形で Drupal にかかわれるようになってきているのだ。それに加え、Acquia のカスタマーには、最近、Acquia Cloud 上での Node.js ホスティングが開始された。これは、開発者にとって、Drupal をコンテンツ リポジトリーとしてうまく利用しながら、JavaScript で最新のアプローチをフルに活用できることを意味する。

新旧を問わず、多くの他の CMS とは違って、Drupal は、様々な組織の多様なニーズに合うようチューニングされた、いくつものアーキテクチャーの可能性を幅広く備えている。完全なデカップリング、プログレッシブなデカップリングの Drupal から従来型の Drupal にまで至る、この柔軟性。それに加え、現場で証明されている各ソリューションの頑丈性。そのおかげで、開発チームは、経験に基づいて自分たちに最適なアプローチを決定することができる。この「選択肢の多様性(オプショナリティー)」こそ、Drupal が他の新しいヘッドレス CMS やほとんどの SaaS プラットフォームとは大きく異なる点だ。また、それは WordPress よりも Drupal の方がデカップル CMS として成熟していることも示している。別の言い方をするなら、どんな(開発)チームであろうと、プロジェクトの要件がどんなものであろうと、Drupal なら回答を出してくれるということだ。

このブログ記事に貢献してくれたプレストン ソーPreston So、そして、この執筆中に意見を聞かせてくれたアレックス ブロンステインAlex Bronstein、アンジー バイロンAngie Byron、ゲイブ サリスGabe Sullice、サミュエル モーテンソンSamuel Mortenson、テッド ボウマンTed Bowman、ウィム リーアスWim Leersに謝意を表したい。