Nuxt + Laravelで開発する上でのメリットデメリット
GameLab開発者の安部です。
こちらのサービスは2020年12月末にサービス終了予定ですが開発の過程で技術選択の意図やその中で生じたデメリットなど今後のためと同じような技術を利用している方のためにこの記事で残そうと思います。
ちなみに筆者はバックエンドがメインでフロントはチームメンバーの方に開発してもらっておりほとんど手をつけていません。
サービスのアーキテクチャ
フロント
バックエンド
Nuxtを選択した理由
当初はVueのみで開発していましたがOGP対応やSEO対策のためにSSRできるNuxtを利用する必要が出てきたため変更しました。そもそもAPIとフロントの開発を分けた理由として開発の高速化のためですがこれによりサイトのレスポンスが非常に遅くなりました。
レスポンスまでの流れとしては
リクエスト -> VercelがSSR始める -> GAEのapi叩く -> apiがSQL叩く -> レスポンス返す -> SSR完了してユーザーまでレスポンス
という流れになります。画像の読み込みはユーザーがサイト周遊中に非同期で行われます。
APIのレスポンスは大体0.2-0.3sでVueのみでの実装をしていた時はTTFBが大体1-2sだったのですがNuxtを導入した後にTTFBが大きく悪化し2-3sになりました。
また、デプロイ先のプラットフォームを当初はFirebaseで行っていたのですがHeroku, Vercelと試したところそれぞれ
- Firebase : 6-7s
- Heroku : 4.5-5s
- Vercel : 2-3s
とコードの変更なしに大幅にレスポンスが変わりました。正直理由はよくわかってません。TTFBの改善はかなり尽力したのですが技術力的に2秒を切るまでの改善にはいたりませんでした。
ちなみにこちらのアーキテクチャはZennのアーキテクチャとほぼ同じであり、GAE + Cloud SQL + Vercelまでは同じで言語がNuxtとNextの違い、LaravelかRailsかの違いがあります。
Zenn開発者の記事では
Next.js 9.4からIncremental Static Regenerationという最高の機能を使えるようになりました。ページにリクエストがあったときに、背後でビルドを行い、次回以降のリクエストではエッジサーバーからキャッシュされたデータを返します。これにより、ユーザーが投稿するコンテンツに対しても、高速なレスポンスを実現できるというわけです。
と記載がありますがこのアーキテクチャで高速なレスポンスを実現するためにはNuxtでフロントを実装してIncremental Static Regenerationを利用すれば早くなるのかもしれません。次回のサービス開発ではフロントはNextを採用します。
Laravelを選択した理由
個人的にPHPを書いたことがなかったため利用したかったためです。
APIのみで利用する場合Laravelがベストかというとそうでもなく例えばこちらはPythonですがFastAPIのようにOpenAPIとの紐付きが強くSwagger Editorを容易に使えるようなフレームワークを利用した方が便利だったかもしれません。
API仕様書を作成していたのですがコードの更新に合わせて仕様書の更新を行うのが非常に面倒でそれなら初めからバリデーションなどを自動で行えて便利なFastAPIを利用していた方が早かったと思います。
ライブラリは
デプロイはGAE、DBはCloud SQLを利用していました。私自身ウェブ開発を始めたのがここ1年程度だったためいわゆるVPSインスタンス上でLAMP環境での開発を行ったことがなくこれらのサービスを利用していましたがGAEのロールバックやCloud SQLのエクスポート機能、自動バックアップなどはボタンぽちぽちで行えるため非常に便利でした。
終わりに
同一のアーキテクチャでNuxtだけどめちゃくちゃ速いよ！って人いましたらコメントくださると嬉しいです。
Discussion