技術・Web access_time2019.11.03 16:52 update

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

 半年ほど前に、こんな記事を書きました。

Image

WordPressからFirebase+Nuxt.jsのHeadless CMSに完全移行するまでの記録 ①導入・技術選定

前置き  2019年4月現在、このブログはWordPressで開発・運用していますが、  それに伴って生じている... 続きを読む

access_time2019-05-02


 簡単にまとめると、

 ・WordPressの重さや脆弱性、jQuery依存などの問題から脱却したい

 ・ Vue/Nuxt、PWA・AMPなどの技術を取り入れづらい

 などの理由から、今使っているこの

 ・記事数5000件超という大規模なWordPressブログを  ・記事データを1つも落とすことなく  ・URLも変えることなく  ・月額費用が一気に高くなったりもせずに

 Firestoreに完全移行したい!という計画です。


 で、途中まで進めていたものの、

 そこから転職して忙しかったり意義を考えたり、あといろんな技術上の課題に突き当たってすっかり止まっていたのですが、

 その会社の方でFirebaseを使ったプロジェクトに携わって、Firebaseの使い方を理解し始めたこと、ある程度技術的なイメージが湧いたことから、

 このFirebase移行プロジェクトを進めることにしました。


 ただ、この半年の間に、Firebase自体も進化しましたし、何よりも自分の知識も増えました。

 4月時点に考えていた構成には、実装上の問題であったり非効率な部分が含まれていて、途中まで進めていたエディター画面なども正直今見ると別に不要だったな……という。


 なので、改めてこのプロジェクトに関するロードマップを引き直すことにしました。


 ……本当は別にこれを記事にする必要はなかったのですが、

 「wordpress firestore」などのキーワードで検索するとまあまあ上位にこのブログが出てしまうという問題に最近気づきまして、ちゃんとやらないと申し訳ないなと……。


 というわけで、以下が新しいロードマップです。


Contents

ロードマップ

フェーズ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は確実に不要です。


技術構成

 フロントサーバーホスティングデータベースエディター
現状PHPPHPロリポップWordPressWordPress
フェーズ1Nuxt.jsNode.jsGoogle App EngineWP REST APIWordPress
フェーズ3Nuxt.jsNode.jsGoogle App EngineFirestoreWordPress
フェーズ5Nuxt.jsなしFirebase HostingFirestoreWordPress

 用語は間違っているかもしれませんが、最終的にはこうなるはずです。


今後の方針

 ここまで書いて気づいたのですが、そもそもGCP要らなくない?

 今すぐにでもWordPressを捨てないといけないのであればともかく、

 最終的にSSRすら使わずに静的サイト化する予定なのであれば、無理にGCP環境にチャレンジする必要もないですし、

 無理にAPI切ったりせずとも、Firestoreからデータを取ってくることだけを考えれば良くなります。

 フェーズ5まで行った段階で初めて公開してドメイン移行すれば良さそうですね。

 私の場合はもう作ってしまったので、フェーズ3の段階で一度公開したくなると思いますが。


 というわけで今日からまずはWordPressとFirestoreの同期にチャレンジしたいと思います! ……たぶんこれが一番大変な気がしますね。それ以外は大体見えてるので。

 目標は年内公開。厳しいと思いますが、頑張ります。

 手順に関してはここに書いた通りでたぶんできるので、知識がある方は別に私の作業を待たずに勝手にやって、躓いたポイントとか教えてほしいですね。


 2020.05追記

 このサイトは既にFirebase/Nuxt構成への移行を完了しており、2020年2月よりFirebase Hosting上で運用されています。最終的な結果を読みたい方は、この記事の内容は無視して上の記事をご覧ください。

Image

Nuxt.js&Firebase で WordPressブログをフルリニューアルしたまとめ

 2020年2月に、WordPressブログ(このサイト)をFirebaseでフルリニューアルしました。  現在このサイ... 続きを読む

access_time2020-05-06

新・WordPressブログをNuxt+Firebaseに完全移行するプロジェクト への{{comments_list.length}}件のコメント

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください


Fatal error: Uncaught Error: Undefined constant "is_single" in /home/users/0/main.jp-identalecords/web/blog/wp-content/themes/osd1904/components/category_posts.php:3 Stack trace: #0 /home/users/0/main.jp-identalecords/web/blog/wp-includes/template.php(785): require() #1 /home/users/0/main.jp-identalecords/web/blog/wp-includes/template.php(718): load_template('/home/users/0/m...', false, Array) #2 /home/users/0/main.jp-identalecords/web/blog/wp-includes/general-template.php(204): locate_template(Array, true, false, Array) #3 /home/users/0/main.jp-identalecords/web/blog/wp-content/themes/osd1904/single.php(124): get_template_part('components/cate...') #4 /home/users/0/main.jp-identalecords/web/blog/wp-includes/template-loader.php(106): include('/home/users/0/m...') #5 /home/users/0/main.jp-identalecords/web/blog/wp-blog-header.php(19): require_once('/home/users/0/m...') #6 /home/users/0/main.jp-identalecords/web/index.php(17): require('/home/users/0/m...') #7 {main} thrown in /home/users/0/main.jp-identalecords/web/blog/wp-content/themes/osd1904/components/category_posts.php on line 3
WordPress › エラー