Web前線(最前線というにはおこがましかった)|WordPress APIが見据えたのは「疎結合なWebな世界」

2016年9月5日

こんにちは、榊原@rdlaboです。気づけば、夏もほぼ終わりで、2016年も7割以上消化してしまいました。本当、日々が流れるものは早いものです。
 
さて、WordPress.comが管理画面をReact.jsを使ってリニューアルをしたのは2015年11月のことでした。その前後から、勉強会のセッションやLTで、WordPressをAPIで叩いたという報告が増え始めたように感じます。
例えば、FRONTEND CONFERENCE 2016で発表があった「NoPHPでWordPressサイトを作ろうとしたら非常に辛かった話」であったり、ブログ「WP REST APIを利用したNodeJSのWebアプリを死ぬ思いで作る」であったりです。

 
「死ぬ」
 
「辛い」
 
「えらいめにあった」
 
大評判なWordPress APIですが、私的にはこれらは「WordPress API」の意図している使い方と違うからこその苦労なんじゃないかなと思うところです。
 

WordPressは閉じた世界だった

制作者が実感しているWordPressの「便利さ」は、管理画面ではないでしょうか。「管理画面からデータを登録する」と、自動的に「フロントが更新される」という出入力を持っているのがCMSであり、ブログシステムであり、WordPressなわけです。そして、WordPressはその世界観の中で超絶進化を遂げました。
 
簡単にいうと、WordPressというCoreシステムには山のようなHackポイントが用意されていて、やりたいと思ったことは公式で公開されてるプラグインを使ったら大体実現できてしまうようになったのです。会員管理、課金、SEO、SNSとの連携、問い合せフォーム、予約管理、アクセス解析、メールマガジンってメールマガジン?!?!
それでも足りなかったら、更に自分でつくることもできます。なんかどっかで「WordPressの記事を電子書籍として出版するプラグインつくりました」みたいな話を聞いた記憶が・・・。
 
WordPressは、これら全てを「WordPress内部で」実現してきたわけです。さすが、日本で大流行、全世界でみても1/4は使われてるといわれてるWordPress!!
とはいえ、これらの進化は、ある意味ガラパゴス諸島ならぬWordPress諸島的進化だったわけです。
 

WordPressを部品として使う「WordPress API」

そうやって閉じた世界で進化を遂げてきたWordPressですが、ここにきて大きく舵を切りました。そう、「WordPress API」を大きく推すようになったのです。例えば、WordPress.com(WordPressのホスティングサービス)は、REST APIのとても丁寧なドキュメントを公開しました。
 

 
また、インストール型のWordPress向けのRestAPI化プラグインも提供されています。
 

 
ちょっとどこで読んだか失念しましたが、プラグインでの拡張ではなく、WordPressのCoreにRest API化機能を積むかも的話もでてたように記憶しています。なぜREST API推しをするかは http://v2.wp-api.org/ に書かれています。
 

WordPress is moving towards becoming a fully-fledged application framework, and we need new APIs.

 
CMSであったり、ブログシステムであったWordPressですが、これからはfully-fledged(立派)な「アプリケーションシステム」になると宣言されています。「アプリケーションシステム」をどう解釈するかですが、私的にはこの文脈だと
 

ミドルウェアの一種で、ユーザが利用するWebブラウザなどのフロントエンド(クライアント)と、データベース管理システムなどのバックエンドの中間に位置する。
http://goo.gl/GSgp2S

 
という意味がしっくりくるなと思っています。つまりは「管理機能に注力するから、フロントエンド(表示部分)はWordPress以外でつくってよ」と。
また、素直に「アプリケーションをつくるためのシステム」と読むこともできます。SPAであったり、ハイブリッドアプリ、ネイティブアプリをつくるためには、PHPでテンプレートがりがり書くんじゃなくて、REST APIじゃないとだめでしょ?と。
 
今まではWordPressはWordPressの中ですべて完結していたのに対して、この流れは「WordPressを部品として使いましょう」といってるわけです。
  

WordPress APIは、代替手段ではない

最初の話に戻りますと、WordPress APIで「死ぬ」「辛い」「えらいめにあった」のは、WordPress APIをWordPressの世界の中で利用したからではないかと思っています。「NoPHPでWordPressサイトを作ろうとしたら非常に辛かった話」
 
「ウィジェットとメニューが使えない」
 
「ほとんどのプラグインが使えない」
 
「プレビュー機能が使えない」
 
という辛かった話がありましたが、これらは「すべてがWordPressで完結する世界」で使われていたものであり、部品のひとつとして使うWordPress APIでは必要ない機能なわけです。全力でやっちゃいけないのです。
そこらどこらで「これからは、WordPressも、APIを使ってReactで構築する時代がやってくる!」みたいな声が飛び交いましたが、今までつくっていたようなコーポレートサイトやブログをAPIを使って作る必要はありません。それらはWordPressの世界で完結するので、従来の手法で作り続けるべきです。
 
WordPress APIが提供するのは、WordPressをパーツのひとつとして、他のシステムと組み合わせてつくるサービスです。例えば以下な感じ。
 

  • Google APIと連携させて、位置情報に紐ついた記事をWordPress APIに挿入する
  • SNSの日記はすべてWordPress APIに挿入して、metaタグでユーザ識別
  • 会員制サービスのユーザ情報をWordPress APIで管理

 
WordPress APIは、WordPress本体と、提供するWebサービスの関係性を「疎結合」にしようとしているわけです。
 
tmp
 

Webはどんどん疎結合になっていってる

Bassのひとつとして、GoogleのFirebaseはここ最近勢いがあります。バックエンド開発しなくても、従量課金でAuthとかDBとか利用できるよー、というサービスなのですが、バックエンド開発もする人としては「まぁ、使うことはないか」と思ってたわけです。
 
が、昨日、@ovrmrw さんが、以下のツイートをしてました。

 
別にFirebase使うっていっても、fullで使ったら(密結合な開発にしたら)大変だから、一部だけ使えば?と。
 
従量制なのでfullで使うと大変なのですが、確かに一部だけの利用(疎結合)な開発は面白いですよね。Auth周りが便利なら、Firebaseで会員ログインを管理して、WordPress APIで記事データ管理して、ブログサービスを提供するとか。そういうこともできるわけです。
 
昔ながらのWeb開発の価値観でいうと、 All in One is better.的な感じがあったのですが、ここ最近のWebの動向をみていると、

  • 密結合より疎結合
  • 集中処理より分散処理
  • ウォーターフォールよりもアジャイル(作っては潰す)

が主流になってきているような感じがしておりまして、WordPress API推しはその代表的な事例だなと感じている今日このごろです。
 
それでは、また。