技術・Web 4年前

新・WordPressブログをNuxt+Firebaseに完全移行するプロジェクト

半年ほど前に、こんな記事を書きました。  簡単にまとめると、  ・WordPressの重さや脆弱性、jQuery依存などの問題から脱却したい  ・ Vue/Nuxt、PWA・AMPなどの技術を取り入れづらい  などの理由から、今使っているこの  ・記事数5000件超という大規模なWordPressブログを ・記事データを1つも落とすことなく ・URLも変えることなく ・月額費用が一気に高くなったりもせずに  Firestoreに完全移行したい!という計画です。  で、途中まで進めていたものの、  そこから転職して忙しかったり意義を考えたり、あといろんな技術上の課題に突き当たってすっかり止まっていたのですが、  その会社の方でFirebaseを使ったプロジェクトに携わって、Firebaseの使い方を理解し始めたこと、ある程度技術的なイメージが湧いたことから、  このFirebase移行プロジェクトを進めることにしました。  ただ、この半年の間に、Firebase自体も進化しましたし、何よりも自分の知識も増えました。  4月時点に考えていた構成には、実装上の問題であったり非効率な部分が含まれていて、途中まで進めていたエディター画面なども正直今見ると別に不要だったな……という。  なので、改めてこのプロジェクトに関するロードマップを引き直すことにしました。  ……本当は別にこれを記事にする必要はなかったのですが、  「wordpress firestore」などのキーワードで検索するとまあまあ上位にこのブログが出てしまうという問題に最近気づきまして、ちゃんとやらないと申し訳ないなと……。  というわけで、以下が新しいロードマップです。

ロードマップ

フェーズ1:Nuxt + WP REST API + GCPでブログを表示する

 フロントのみをNuxt化し、WordPressに備わっているWP REST APIで必要なデータを取ってくる、ということです。  OGPなどの理由からSPAではなくSSRします。後々Firebaseと連携することも考慮して、Node.jsの無料枠があるGCPを選びましょう。  実はこれについては年始に途中まで進めていたものがあるので、ほぼ完了しています。  正直やり方は覚えてないので、SSRで表示するところまでの記事は詳細には書きません、ごめんなさい。
Nuxt.js v2とGAE/SE Node.jsでSPA×SSR×PWA×サーバーレスを実現する|DMM inside App Engineの標準環境でNuxtを使って無料SSR - Crieit  WordPressサイトのURL構造をクローンする方法は書くかもしれません。 https://osd-nuxt.appspot.com/ (※記事投稿時点での情報なので、その後更新されている可能性があります)  この時点では、記事投稿・データベースにはWordPressを利用しています。  Nuxtで表示はしていますが、静的サイト化ではなくSSRですし、結局ロリポップのサーバーを見に行っているので速度的に向上もしないでしょう。 (キャッシュなどを使って部分的に高速化はできるかもしれませんし、脱jQueryできるのでフロント側の速度は上がるかもしれませんが、根本的な解決ではない)

フェーズ2:FirestoreとWordPressのDBを同期させる

 FirebaseにはCloud Functionsという機能があり、外部からGET, POSTなどのメソッドと一緒に叩くことで特定のNode.js操作を実行してくれる機能があります。  これを利用して、WordPress投稿時にその記事データを自動でCloud Functionsに投げさせれば、自動でFirestoreにも記事が投稿されていく仕組みが作れるはずです。(※無料枠でできるかどうかは不明です)  現在WordPressに存在している全ての記事を特定のタイミングで一度コピーしてしまえば、あとは常にWordPressとFirestoreの同期が取れるはずです。  同様のことを記事だけでなくコメント・固定ページ・カスタム投稿タイプに対しても行えば、ブログ閲覧に際して必要なデータが全てFirestoreに渡ります。

フェーズ3:Nuxtでデータを見に行く先をFirestoreにする

 WP REST APIから取っているデータをFirestoreに変えます。APIをきっちり分けておけばここは対応できるはずです。  Firestoreからデータを取ってくる際に制約となるのは、 ・別テーブルの情報を一発で取ってこれない(クライアント側で2回リクエストして取ってくる必要がある。ただし、ブログレベルだとあまりデメリットにはならなさそう。関連記事のリンクを取ってくるのがちょっと辛いかも) ・offset指定ができない(例えば投稿日ソートするなら、startAfterで日付を渡してそれ以降を10件、みたいな指定になる) ・キーワード検索ができない  このキーワード検索だけがネックで、Algoriaなどの外部サービスと連携させる必要がありそうです。 https://firebase.google.com/docs/firestore/solutions/search?hl=ja  逆に言えば壁になりそうなのはほぼキーワード検索のみと言って良いでしょう。Algoriaと繋げるつもりですが、ここから2ヶ月くらいでFirestore公式にもう少しマシなソリューションが追加されないかなーと淡く期待しています。

フェーズ4:コメント・いいねの投稿先をFirestoreにする

 これはその名の通り。むしろ本来のFirestoreの使い方なのであんまり苦労しないと思います。  commentsやlikesのサブコレクションに書き込み権限を与えるか、cloud functionsでどうにかするかは、考え中です。  これを行うことで、WordPress側には存在せずFirestoreにしかない情報がついに生まれ始めます。

フェーズ5:記事を投稿するたびに自動で静的サイト化・デプロイが行われるようにして、JAMStack化する

 そもそもREST APIでJAMStack化できないのは、5000件もあるこのブログの記事のデータを静的サイト化のために取得しようとするとロリポップさんが確実に落ちるからであって、  無限のパワーを持つFirestoreであれば、記事更新のたびにリクエスト10000件投げてもたぶん大丈夫ですよね?無料枠でも1日50000回まで読み取り可能らしいですし、従量制でも10万回読み取るごとに6円。  静的サイト化するということは、デプロイ時以外にはFirestoreへのリクエストが行かなくなるということでもあるはずなので。……まあ実際には、コメントやサイドバーなどは静的サイト化せずにクライアントから取りに行っても良さそうですが。  ここまで行けば悲願のJAMStack化が達成されます。  自動で静的サイト化は、NetlifyならGitHubにpushするたびに更新できますが、Firebase Hostingだとどうするんだろう? やはりCircleCIになるのでしょうか。 Circle CIからFirebase Hostingに自動ビルド&デプロイする - Qiita  この記事が参考になりそうです。

フェーズ6:WordPressのレンタルサーバーとGCPを解約する

 この時点で、WordPressの機能は「記事投稿時に投稿内容をFirestoreに投げるだけ」になっているはずです。  エディターとしてWordPressを使うのだとしても、この機能であればWordPressサイトをローカルに作っても良さそうですよね。  とはいえバックアップとしては使えますし、わざわざ自作する理由もそんなになさそうなので、月250円ならしばらくは持っていても良いのかなと思います。  脆弱性に関しても、POSTしかしないならWordPressサイトごとbasic認証かけてしまって問題ないはずです。  フェーズ5で静的サイト化した時点でFirebase HostingかNetlifyに上がっているはずなので、SSRは確実に不要です。

技術構成

 フロントサーバーホスティングデータベースエディター
...

comment  0
favorite  3