refirio.org

Next.jsを使う

★検討中メモここから laravel/breeze-next を使わずに、通常の手順でNext.jsを作る方がシンプルでいいか。 つまり、frontendディレクトリを設けてその中にNext.jsプロジェクトを作成し、同じリポジトリで管理する。 Laravelは breeze:install で api を指定して動作させる。 個別に動作できる、疎結合の状態を保つ…というのがいいか。 ただしその場合、認証機能を作るのが大変になるなどのデメリットもあるか。 現状はsailで検証しているが、これはあくまでも開発環境用となる。本番環境用に、ECS検証のexampleを使ってマルチステージビルドで検証するか。（最終的にマルチステージビルドで構築するかどうかはともかく。） Nginx(80)、Next.js(3000)、Laravel(8000)という構成が素直か。 NginxとLaravelを同居させるのだから、Next.jsも同居させるのは自然だと思われる。 クライアントサイドとサーバサイドでリポジトリが分かれていても更新が面倒そうな。大人数が関わる大規模開発なら、分ける方がいいのかもしれないが。 Findy転職フロントエンドの開発生産性を向上させるためにやったこと - Findy Tech Blog https://tech.findy.co.jp/entry/2024/05/13/083000 > 前述の通り Findy は Rails モノリスで作られており、CI にフロントエンドとバックエンドの両方が含まれていることから、画面の文言を1つ更新するだけでも長い CI 待ちが発生します。 > この状況を打破するために、Findy で最初に行われた取り組みは「Rails モノリスの解体」でした。 > 約3ヵ月かけてバックエンド側を Rails の API モード、フロントエンド側を Next.js で再実装するという大掛かりなプロジェクトでしたが、これによりフロントエンドとバックエンドで独立して動けるようになったため、先述した CI 待ちを大幅に短縮できました。 これがリポジトリを分けるメリットか。 ただしフロントエンドとバックエンドの両方をデプロイする必要がある改修なら、結局は両方の合計時間が必要となる。 やはり「小さなプロジェクトならモノリスでもいいが、ある程度大きなプロジェクトなら分離している方がいい」ということか。 分離させるとして、ECSを使っているなら「フロントエンド用のECS一式」と「バックエンド用のECS一式」が必要になるか。それはそれで維持コストも倍になるデメリットはある。 Next.js自体が複雑化してしまったので、Remixという別のフレームワークを使おう…という動きもあるらしい Remixについては以下のファイルを参照 Dropbox\技術\Remix.txt ★検討中メモここまで 以下などのページが参考になりそう。 おおまかに ・「breeze:install」の際に「react」ではなく「api」を指定し、Laravelをバックエンドとして使用する。 ・別途フロントエンド用に、「breeze-next」のリポジトリからクローン。 という流れになるみたい。 GitHub - laravel/breeze-next: An application / authentication starter kit frontend in Next.js for Laravel Breeze. https://github.com/laravel/breeze-next Laravel Breeze+Next.jsのインストールと認証機能の作成 | アントレプログラマー https://entreprogrammer.jp/laravel-breeze-install/ LaravelとNext.jsを一緒に利用できるって知ってました？ | アールエフェクト https://reffect.co.jp/laravel/laravel-breeze-next-js Laravel×Next.jsでの認証方法 ~スターターキットとテンプレートの中身をみる〜 https://zenn.dev/ritton/articles/deb07ba987db38 Laravel（Laravel Breeze） + Next.jsのローカル開発環境構築｜shinya https://note.com/shinyeah/n/ndd9088ed746b Next.js + LaravelでCRUD機能を作成する #Laravel - Qiita https://qiita.com/masakiwakabayashi/items/5286e61f5cb664e1dab9 Next.js × Laravel でページネーションの実装 #PHP - Qiita https://qiita.com/mosyaneko/items/f4f1ec4c8c25298e8aab ■準備 ※いったん、この対応は行わずに進める。（デフォルトの設定に合わせて localhost でアクセスする。） ※最終的に「localhost:80（Nginx） → localhost:3000（Next.js） → localhost:8000（Laravel）」のような構成になるか。 C:/windows/System32/drivers/etc/hosts ■インストール ブラウザから以下にアクセスして確認。 http://localhost/ ■環境の調整 前述の「初期設定」を参考に作業。 ■デバッグバーの導入 前述の「初期設定」を参考に作業。 ■Next.jsの導入 まずは laravel/breeze-next を導入する。 .git と .github を削除しているのはGit管理にするためだが、この方法が良いかどうかは要検討。 Docker環境に合わせて、frontend/.env.local を以下のとおり調整する。 続いて laravel/breeze を導入し、APIとして動作させる。 「sail artisan breeze:install api」により、.env の内容が以下のとおり変更されている。 Docker環境に合わせて、以下のとおり調整する。 コンテナを終了させる。 docker-compose.yml に frontend の項目を追加。 コンテナを起動させる。 ブラウザから以下にアクセスすると、「{"Laravel":"10.48.10"}」とだけ表示される。（APIモードに変更したため。） http://localhost/ ブラウザから以下にアクセスすると、Laravelの画面が表示される。（Next.jsで出力されたもの。） http://localhost:3000/ また通常のLaravelと同様 /register からユーザ登録ができ、 /login からログインしてマイページも表示できる ■ポートの変更について 上記の手順ではLaravelが80番ポートで、Next.jsが3000番ポートで動くことになる。 Laravelは8000番ポートのままとし、別途Nginxを80番ポートで動作させてLaravelを参照させるべきか。 ■URLの変更について laravel-next.local などのドメインでアクセスすると、不正なドメインとみなされて投稿できないみたい。 以下あたりを調整することで対応できそうだが、まだ解消できず。 frontend/.env.local .env ただし前述のとおり、最終的にNginxからのアクセスを3000番ポートで受け付けることになるか。 それならドメインは変更せずに、localhost のまま進めるべきか。 ■日本語化について 以下のとおり、ビルド時にエラーになった。package.json が見つからないとある。 「認証機能の作成」のタイミングで、以下のファイルが削除されているような。 package.json vite.config.js resources/css/app.css resources/js/app.js resources/js/bootstrap.js resources/views/welcome.blade.php frontend ディレクトリ内でビルドする必要があるか。 また確認したい。 ■ページの作成例 frontend/pages/hello.js を作成。 「/hello」にアクセスすると「Hello!」と表示される。 表示されない場合、コンテナを再起動する。 （↑別の正しい方法があると思われる。要調査。） ■ページの作成例（レイアウト使用） frontend/components/Layout.js を作成。 frontend/pages/hello.js を作成。 「/hello」にアクセスすると「Hello!」と表示される。 ■引き続き ・「ポートの変更について」「URLの変更について」「日本語化について」について調べておきたい。 ポートやURLは、そもそもリポジトリ自体を分けることが推奨されるか。 ・ログイン後の情報編集機能が無いのは、単に実装されていないだけか。 ・ReactとNext.js自体について調べる。