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

Drupal 標準のテンプレート レイヤーを使って Web サイトを作るか、それとも、JavaScript フレームワークを組み合わせて Drupal のデカップルまたはヘッドレスの能力を使うか

コンテンツ管理の革新は加速してきている。それは、CMS が対応する必要のあるチャネルの数（Web、モバイル、SNS、チャット）においても、従来の Web チャンネルにおける JavaScript フレームワーク対応へのニーズにおいてもいえることだ。その結果として、ヘッドレスあるいはデカップル型アーキテクチャが台頭してくる様子を僕たちは見てきた。

デカップル型 Drupal は Drupal コミュニティーのあらゆるところで採用されてきた。デカップル型アーキテクチャへと向かうトレンドに応えるかたちで、僕は 2016 年と 2018 年にアーキテクトと開発者のためのブログ記事を書いた。いつ、どうやって Drupal をデカップルするべきかという話だ。前回の記事を書いたときから周囲の状況も進化したし、Drupal の Web サービスもさらによくなった。そして、静的サイトジェネレーターや JAMstack などの新しいパラダイム（規範）も登場してきている。

（そういうわけで）2019 年用に僕の推奨方法を更新するときが来た。去年と同じように今年度用フローチャートの全体像から行こう。

Drupal をデカップルするさまざまな方法

Drupal をデカップルするために確立された方法のいくつかを再検討し、普及が進んでいる新しいパラダイムも考察してみようと思う。以前にも書いたとおり、デカップリングの立場から見た Drupal アーキテクチャでいちばん一般的な 3 つのアプローチは、従来型（またはカップル型）、プログレッシブなデカップル型、完全なデカップル型だ。こうした異なる種類の Drupal デカップリングが存在するのは（開発者や利用者の）好みや要件がさまざまであることから来ている。

従来型の Drupal では、Drupal が通常備えている働きはすべてフルに機能する。Drupal はモノリシック（一枚岩型）システムなので（コンテンツの）表示とデータ レイヤーに対して完全な制御を保持する。インプレース編集やレイアウト管理といった機能も利用できるので、ページ上のビジュアルな要素をフルに制御する必要がある編集者にとって、従来型の Drupal は素晴らしい選択であり続ける。これは僕たちが昔からずっと知っているタイプの Drupal だ。利用するメリットがリアルにわかるので、今でもまだほとんどのコンテンツ管理プロジェクトはこのやり方で構築される。

ときどき、高度にインタラクティブなエンドユーザー体験を提供するために JavaScript が求められることがある。その場合、デカップル型のアプローチが要求される。プログレッシブなデカップル型の Drupal では既存の Drupal フロントエンドの上に JavaScript フレームワークがレイヤーとして使われる。この JavaScript には、ページ上にある単独のブロックや構成要素をレンダリングする役目しかないこともあれば、ページのボディー内にあるすべてをレンダリングすることもあり得る。プログレッシブなデカップリングのパラダイムには連続的な広い幅がある。JavaScript に割り当てられたページ範囲が少ないほど、編集者にとっては Drupal の管理機能を使ってページをコントロールできる割合が増えることになる。

今年に至るまで、フルデカップル型の Drupal はデカップル型 Drupal アーキテクチャの単独カテゴリーであって、プレゼンテーション（表示）レイヤーと、CMS に備わったその他すべての観点における事柄の完全な分離を表している。このシナリオでは、CMS は 1 つのデータ供給者であって、サーバーサイド レンダリングの JavaScript アプリケーションがすべてのレンダリングとマークアップを担当し、Drupal とは Web サービス API 経由でやりとりを行う。インプレース編集やレイアウト管理といった主要な機能は利用できない。しかし、フルデカップル型の Drupal は、フロントエンドをもっと広範囲に制御したい開発者、Angular、React、Vue.js などのフレームワークでアプリケーションを作った経験がすでにある開発者の心を引きつけている。

JavaScript の開発がますます複雑になってきているせいでフルデカップル型の Drupal は昨年 1 年の間に 2 つのパラダイムに分かれた。いわゆる JAMstack（JavaScript、API、Markup）はフルデカップル型の静的サイトという新しいアプローチをもたらすものだ。静的サイトにする主な理由としては、パフォーマンスの改善、セキュリティー、そして、開発者にとっての複雑度が下がるという点が挙げられる。Gatsby のような静的サイト ジェネレーターは Drupal からコンテンツを取得してひとつの静的な Web サイトを生成し、通常は Netlify などの特化したクラウド プロバイダーを通じて、その静的サイトを CDN にデプロイする。

何を構築しようとしているか

いつものことだが、本質的な問いは「何を構築しようとしているのか」ということになる。以下は 2019 年のデカップル型 Drupal を調べているアーキテクトのために更新したアドバイスだ：

1. スタンドアローンの単独 Web サイトまたは Web アプリケーションを作ろうとしているのなら、デカップル型 Drupal は正しい選択にもなり得るし誤った選択にもなり得る。それは自分の開発者たち、編集者たちがどんな要件を必須と考えているかよる。
2. 複数の Web 体験（Web サイトまたは Web アプリケーション）を構築しようとしているのなら、デカップル型 Drupal インスタンスを a) 外部に向いている独自のフロントエンドを持たないコンテンツ リポジトリ、または b) コンテンツ リポジトリとしても機能する従来型の Web サイトとして使用できる。意図しているアプリケーションがどのくらい動的な必要があるかによって、高度にインタラクティブなアプリケーションの場合は JavaScript フレームワークを選べばいいし、ほとんどの静的な Web サイトには静的サイト ジェネレーターを選ぶのがいいだろう。
3. 複数の非 Web 体験（ネイティブのモバイルまたは IoT アプリケーション）を構築しようとしているのなら、デカップル型 Drupal を利用して Web サービス API を外部に開き、自分では外部向けフロントエンドを持たないコンテンツ リポジトリとして、その Drupal サイトを使えばいい。

Drupal がこれだけパワフルである理由は、これらのユース ケース（使用形態）をすべてサポートしているということだ。JSON:API、GraphQL、OpenAPI、CouchDB といった広く認知された標準規格のおかげで、デカップル型 Drupal を構築するのはシンプルになっている。結局のところ、次に構築するアーキテクチャをデカップル型 Drupal にするべきかは技術的な要件によって決まることになる。

技術的な要件に加えて組織的な要因が絡んでくることもよくある。たとえば、Twig の知識がある優秀な Drupal フロントエンド開発者を見つけるのは、なかなか大変だ。だから、もっと手近な JavaScript 開発者を採用してフルデカップル型の実装を構築する方がより理にかなっているということもあるだろう。

不可欠なものがあるか？

昨年の記事にも書いたように、Drupal のデカップリングでどういう決定を下す場合でもいちばん大事な観点は、自分のプロジェクトで求められる機能・要件のリストを作ることだ。編集者と開発者のニーズを注意深く検討しなくてはならない。これはさまざまな長所・短所を天秤にかける評価プロセスのなかでも極めて重要なステップだ。どんなプロジェクトにおいても、組織全体にわたって存在する数々のニーズを正確にとらえて評価しなくてはならない。

編集者チーム、マーケティング チームの多くが特定の CMS を選択するのは、その CMS のレイアウト機能や豊富な編集機能があるためだ。たとえば、Drupal の場合、編集者はブラウザー内でレイアウトを作ってそこに構成要素をドラッグ アンド ドロップすることができる。開発者が編集者のためにその作業をしてあげる必要はない。CMS に備わっている機能の多くをコンシューマー向けアプリケーション上に再構築することは可能だが、それには時間もコストもかかるプロセスになりがちだ。

ここ数年の間に開発者体験も考慮すべき事柄として重要になってきたが、それは僕たちが期待するであろうものとはいささか違ってきている。JavaScript 界隈（かいわい）に見られる変化の多くは開発者たちがデカップル型 Drupal を好むようになるモチベーションのひとつではあるが、Drupal 用のフロントエンドの書き方が今やいくつもあるという事実によって、デカップル型 Drupal のプロジェクトに取り組める人材を見つけやすくなっているのだ。例を 1 つ挙げるなら、多くの組織は Twig の経験があるフロントエンドの Drupal 開発者を予算内で見つけるのは難しいと感じている。それが、JavaScript 駆動型のフロントエンドに移行することによって、こうしたリソースの問題のいくつかは解決できるだろう。

こうして、開発者たちが優先する要件と編集者たちの優先要件とのバランスをとっていけば、自分たちのニーズにとって適切なアプローチにたどり着けることだろう。自分の属する組織がほとんど編集者寄りなら、デカップル型 Drupal は問題になりかねない。それは、編集者にとって自分のコンテンツのプレゼンテーションを制御できる分量が減ることになるからだ。同様に、自分の組織が開発者リソース寄りなら、フルデカップル型の Drupal には発展を加速できる潜在的な可能性がある。ただし、その際に注意する必要があるのは、不可欠な編集機能の多くがなくなってしまうということだ。

考慮すべき現在・未来のトレンド

昨年 1 年間で JavaScript フレームワークはより複雑になったが、その一方で静的サイト ジェネレーターはより単純になった。

JavaScript 界隈について僕が耳にしたよくある苦情のひとつは、どんどん複雑になっているせいで分裂状態、結束力のなさが目に付くということだ。静的サイト ジェネレーターにとっては、それが駆動力となってきた。2 年前ならほとんどの JavaScript 開発者は単純な Web サイトを作るためだけにさえも Angular や Ember といったフル機能のフレームワークを選んだだろうが、今日だったら静的サイト ジェネレーターを選ぶかもしれない。静的サイト ジェネレーターでも JavaScript は使えるし、パフォーマンスに関して考慮するべき事柄や構築プロセスは開発者の責任ではなくホスティング サービス側に任せればいいからだ。

静的サイト ジェネレーターはポジティブな開発者体験を与えてくれるので今後 1 年の間に勢いを得るだろうと僕は予測する。静的サイト ジェネレーターは、経験を積んだ開発者と経験の浅い開発者の両方にまたがる中間領域も引き寄せている。

まとめ

Drupal はデカップル型アーキテクチャーにとって引き続き理想的な選択肢であり、さらによくなり続けている。「API ファースト」イニシアチブは JSON:API モジュールを Drupal コアに入れるための準備を大きく進展させている。また、管理 UI と JavaScript モダナイゼーション イニシアチブは再考案した管理インターフェイスで Drupal の Web サービスを使ってみることに取り組んでいる。GraphQL に対する Drupal のサポートも改良が続いているし、デカップル型 Drupal というテーマに絞った本さえも出た。デカップル型アーキテクチャ用に Drupal が提供する豊富な機能・性能群を利用することで今日の開発者には幅広い取り組み方が与えられているのは明らかだ。

開発者が選択できる新たなアーキテクチャのパラダイムとしてフルデカップル型の静的サイトがもたらされ、アーキテクチャ的な可能性が以前よりもさらに広がった。去年、僕が定義したデカップル型 Drupal のアプローチ群がいっそう広範囲になったことになる。WordPress、Sitecore、Adobe といった Drupal の競合をはるかに超えた機能群と共に、この柔軟性によって、Drupal は従来型とデカップル型どちらのアプローチにも素晴らしい CMS であることを明示し続けている（訳注：「…はるかに超えた機能群」は「デカップル型のアプローチ」にかかっていると解釈できる）。担当チームの構成や組織のニーズがどんなものであろうとも、Drupal には、みなさんにとってのソリューションがある。

このブログ記事を共同執筆してくれたプレストン ソー（Preston So）に特別な謝意を表したい。そして、アンジー バイロン（Angie Byron）、クリス ハンパー（Chris Hamper）、ゲイブ サリス（Gabe Sullice）、ローリ エスコラ（Lauri Eskola）、テッド ボウマン（Ted Bowman）、ウィム リーアス（Wim Leers）には、この執筆プロセス中にくれたフィードバックに感謝する。