実務未経験エンジニアがLaravel&ReactでWebアプリケーション開発に挑戦してみた！（その７）

0. 初めに

皆さん、こんにちは！荒木.phpと申します。

このシリーズでは、実務未経験エンジニア（就職はしたけど研修期間中）の僕が、一からWebアプリケーション開発に挑戦する記録を投稿しています！
今回から、バックエンド実装編ということで実際にアプリケーションの機能を作っていこうと思います！

目的

・自分の作業記録を残して、後から見直せるようにしています。
・また、同じく未経験の方や初心者の方に共感していただけるような記事を投稿することで、読んでくださっているあなたのモチベーションアップも図っています！

ここまでの振り返り

このシリーズでは、これまでに要件定義・設計編、さらに環境構築編を投稿してきました。気になる方は、ぜひご覧になってください！

Dockerを使って環境を構築し、Laravelのインストールをし、さらにはGitリポジトリの作成まで完了しています！

また、シリーズのこれまでの記事全てを載せておきましたので良かったらどうぞ～

これまでの記事一覧

要件定義・設計編

・その１: 要件定義・設計編

環境構築編

・その２: 環境構築編① ~WSL, Ubuntuインストール~
・その３: 環境構築編② ~Docker Desktopインストール~
・その４: 環境構築編③ ~Dockerコンテナ立ち上げ~
・その５: 環境構築編④ ~Laravelインストール~
・その６: 環境構築編⑤ ~Gitリポジトリ接続~

1. MVCアーキテクチャについて

さっそく実装に入りたいところですが、まずは今回Laravelで開発するうえで、中核となる非常に重要な概念であるMVCというものをご紹介してからにしましょう！

MVCというのはアーキテクチャの一種と言われていています。
そう聞くと一気に難しそうに聞こえますね💦
アーキテクチャは、「構成」とか「構造」と言い換えてもいいかもしれません。

アプリケーションを作るとなっても、どのようにデータを取ってきて、それをどのように処理して、どのように画面に表示するかなどを決めておかないと作っているうちにぐちゃぐちゃになってしまいます。

レストランでも注文を聞く人がいて、それを受けて料理をする人がいて、提供する人がいて...というように役割分担がされています。
同様にWebアプリケーション開発のプロジェクトにおいても、ファイルごとに役割分担していくことで、効率的に開発を進めることができというわけです！
さらに、開発の効率アップだけなく、保守性や再利用のしやすさも増します。

よって、このアーキテクチャにそって開発を進めていくことが重要です！

MVCとは？

では、MVCとは何なのかという説明ですが、これは三つの英単語の頭文字になっています。それらが、モデル（Model）、ビュー（View）、コントローラー（Controller）の三つです！

モデル（Model）とは？

要件定義・設計編で少し触れましたが、ユーザーの情報や今回で言うと投稿されたレビューの情報などは、データベースに保存されています。
モデルは、このデータベースを操作・管理する役割を果たしています。

ビュー（View）とは？

ただし、データベースは通常、SQLという特殊な言語を使用しないと中身を見ることができません。ITエンジニアの方ならまだしも、普通の人はSQLを書けないので、中身を見ることができません。

実際にユーザーがブラウザ（←Google ChromeとかMicrosoft Edgeとか）等でアプリケーションの画面を見ると思いますが、その画面にデータベースの内容をどのように表示するかを決めるのがビューの役割ということになります。

同じく、要件定義・設計編で、ワイヤーフレームを作成していますが、これがビューの構想でございます。

コントローラー（Controller）とは？

では、最後にコントローラーについてお話しします。
コントローラーの役割はずばり、これらモデルとビューの橋渡しをすることです！

ユーザーがビューで入力した内容をモデルに渡して保存したり、あるいは、モデルがデータベースからとってきたデータを処理してビューに渡してユーザーが見られるようにしたりと重要な役割を果たしています。

これ以降は、モデル・ビュー・コントローラーにそれぞれの役割をうまく分担させられるか（一部にだけ長ったらしく処理を担当させない）が可読性が高く、運用がしやすくなるかの鍵となるので、一緒に腕を磨いていきましょう！

2. Inertiaセットアップ

次に、Inertiaのセットアップ及び認証機能の実装のために、Laravel Breezeというものをインストールします！

おい、もう環境構築編は終わったはずだろ！なんでまたインストールなんだ!!??

と思ったかもしれません。本当にプログラミングは、インストールが多いですよね💦

Laravel Breezeとは？

このBreezeとは、一部の機能が既に実装されたもので、インストールするだけでそれらの機能を自分のプロジェクト内で実現することができるという、いわば手抜きができる便利なものです！（笑）

Breezeでは、認証機能（会員登録とかログインとか）が既に実装されています。
よって、Breezeをインストールさえすれば、認証機能を自分で一から実装しなくてもOKということです！

Inertia.jsとは？

では、もう一つ気になるのが、Inertiaだと思います。
Inertiaとは何なのか？

その前にそもそも今回の開発でやりたいことは何だったのかを確認しましょう！
シリーズのタイトルにもあります通り、今回の開発では、LaravelとReactを組み合わせてみようという試みがあります。

Laravelは、phpという言語のフレームワークで、主にバックエンド（裏側のサーバー側で動く仕組みを作る）を担当します。
Reactは、JavaScriptという言語のライブラリで、主にフロントエンド（ユーザーの画面側の動きなどを作る）を担当します。

ここで、先ほどのMVCの話に戻ります。Laravelには、これらM・V・Cのすべてが標準搭載されていて、MVCで開発するのに非常に適しています。
ところが、上述の通り、Laravelはバックエンドに重きを置いています。
もちろん、LaravelだけでもWebアプリケーション開発は十分にできますが、やはりよりクオリティの高い画面を作るには、JavaScript（ひいてはそのライブラリであるReact等）の活用が不可欠です。

したがって、今回は、MVCのVの部分をReactに担当してもらおうというわけです！

しかし、LaravelとReactを組み合わせるには、従来はAPIエンドポイントというものを作成するなどをする必要がありました。
ところが、Inertia.jsは、LaravelとReact間のデータのやり取りをスムーズで簡単なものにしてくれます！

公式のドキュメントを読むと、

Think of Inertia as glue that connects the two.

と書かれています。Inertiaを二つのものをくっつける接着剤だと思うと、イメージが付きやすいということですね!!

対象の方だけお読みください

なお、今回のシリーズでは、phpやJavaScriptの基本的な文法は、さすがに紹介しきれないので、恐れ入りますが、学習経験がない方は各自で事前に勉強しておいてくださると、この後の説明もわかりやすくなると思います。

YouTubeとかで「php 入門」とか「JavaScript 入門」とかで検索すると、たぶんいろんな人が解説していると思いますので、それを一つ見て、余裕があったらProgateなどのサービスを利用して実際に手を動かしてみることをお勧めします。

一つのプログラミング言語を真剣に勉強しようとすると、実はかなり奥が深いので長い時間がかかってしまいます。細かいところはいったんおいておいて、ざっくりと概要を掴む程度でよいと思います。
基本を掴むだけなら、２週間もかからないと思います。
今回の開発でも、今のところそこまで難しい知識は必要がない予定です。

作業ブランチの運用について

Breezeをインストールする前に、本プロジェクトのGitのブランチ運用について確認した後、実際にInertiaのセットアップ作業用のブランチを切ってチェックアウトしたいと思います。

前回の最後にGitを使って、ローカルのmainブランチを作成してリモートのmainブランチにプッシュした状態です。
つまり現状は、ローカルとリモートともにmainブランチだけがあり、中身は一緒という状態です。

※ちなみに、GitHubでは新規のブランチ名をmasterではなく、mainにするように推奨しています。おそらくこれは、歴史的な背景から支配と従属の関係を連想させるような言葉を極力使わないようにすることで、一部の開発者が不快な気分にならないようにしたいという配慮からだと思います。

すみません。前回最後のたとえ話では、説明を分かりやすくするためにmasterにしてしまいました。
てか、思い切り「master（ご主人様）」とか「顧客（神様）」とかいう表現を多用してしまい、一部の方に喧嘩を売っていると捉えられる可能性がある表現をしてしまいました。
そのような意図はございませんので、ご安心ください。
また、万が一不快に思われた方がいらっしゃいましたら、大変申し訳ございませんでした。

気を取り直して、ブランチ運用の説明に戻ります！
今回は、以下のような運用の仕方をしてきたいと思います。

main（本番環境用ブランチ）
└── develop（開発の統合用ブランチ）
    ├── feature/01-setup-inertia
    ├── feature/02-auth
    └── feature/03-review-crud

見ていただいている通り、mainブランチを本番環境用のブランチとしてとっておいて、そこから開発用のdevelopというブランチを切ります。
さらにdevelopから分岐したfeatureブランチを切って、実際の開発作業を進めていき、作業が完了したらdevelopにマージしていくという感じでやっていきたいと思います。

作業ブランチの切り替え

では、新規ブランチを切ります！
Ubuntuを開いて、~/project-root/srcまでcdで移動しましょう。
移動出来たら、以下のコマンドを実行して、念のため現在いるブランチを確認しておきましょう。
実行コマンド

~/project-root/src

$ git branch

実行結果

現在mainブランチにいることが分かります。次に、以下を実行して、mainブランチからdevelopブランチを切ってそこにチェックアウトしましょう！
実行コマンド

~/project-root/src

$ git checkout -b develop main

実行結果

どうやら、新しいdevelopブランチに切り替えられたようです。
念のため、もう一度現在のブランチを確認しておきましょう！
実行コマンド

~/project-root/src

$ git branch

実行結果

developにちゃんと切り替わっている！

ちなみに、git checkout [ブランチ名]でブランチの切り替え（前回の比喩で言うところの平行世界を移動すること）ができます。
-bオプションを付けることで、git checkout -b [新規のブランチ名] [派生元のブランチ名]のようにして、新しいブランチを切ってさらにそのブランチにチェックアウトできます！

このdevelopはローカルにしかないので、リモートにプッシュしてあげます（ファイルの中身は変更していないのでコミットは不要）！
実行コマンド

~/project-root/src

$ git push -u origin develop

originというのは、慣習的にリモートリポジトリのブランチであることを暗示するためのものです。したがって、このコマンドは「リモートリポジトリのdevelopブランチにプッシュするよ」という意味です。
ただし、リモートの方にはdevelopはまだありませんので、初回は-uオプションを付けておくことで紐づけがされます。

GitHubを開いて、自分の作成したリポジトリ（今回はlab-review-app）のBranchesを見てみると、確かにdevelopが追加されていることが分かります！

次に、今回の作業である「Inertiaをセットアップする」という作業のためのfeature/01-setup-inertiaという名前の作業ブランチを切っていきます。
ちなみにこの「feature」という単語は「機能」という意味らしく、新機能を開発している今にぴったりのネーミングです！

Ubuntuに戻って、以下のコマンドを実行します。
実行コマンド

~/project-root/src

$ git checkout -b feature/01-setup-inertia develop

実行したら、また、git branchで現在のブランチを一応確認しておきましょう。

ブランチが切り替わっていますね！

以降の作業はこのfeature/01-setup-inertiaで行うため、勝手に他のブランチにチェックアウトして作業し、コミットしないように気を付けてください！（笑）
不安な時は、何度で～も♪、git branchで確認してください。(≧◇≦)

Breezeをインストール

では、Breezeをインストールします。
先ほどBreezeは認証機能を実現するためのものと説明しましたが、実はInertiaのセットアップもこのBreezeをインストールすることで行うことができます（Breezeを利用せず、Inertiaに必要なものを自分で一つ一つインストールしていくこともできます）。

Dockerコンテナを立ち上げていない場合は、Docker Desktopを開いてコンテナを起動しておきましょう。
そうしたら、またUbuntu上で以下のコマンドを実行して、起動中のコンテナを確認してください。
実行コマンド

~/project-root/src

$ docker ps

実行結果

改行されちゃっていてわかりにくいかもしれませんが、一番右のNAMESのところから、phpのコンテナであるphp-labというのをコピーしておきましょう。

次にこのphpのコンテナ内に入ります。コンテナ名の部分にphp-labを張り付けましょう（コンテナ名が違う方は、その別のコンテナ名を貼り付けましょう）。
実行コマンド

~/project-root/src

$ docker exec -it php-lab bash

そうしたら、次のコマンドでBreezeをLaravelにインストールします。
Composerを使用します。
実行コマンド

/var/www

$ composer require laravel/breeze --dev

さらに、Reactを使えるようにします！artisanコマンドです。
実行コマンド

/var/www

$ php artisan breeze:install react

終ったら、VS Codeを開いていただいて、src/resources/views/app.blade.phpというファイルを開いて見てください。
以下のように20行目にinertiaの文字が確認できます。

なお、ファイルをフォルダを開いて探していくのが面倒な場合は、「Ctrl」+「p」で画面上に検索欄が出るので、さっきのパスをコピペしていただけるとフォルダを一つ一つ開かなくても直接ファイルを開くことができます。

これにて、Inertiaのセットアップ作業は完了です。

コミット・プッシュ

では、ファイルに変更がなされたのでコミットしましょう。
以下のコマンドを順番に実行して、プッシュまで完了させましょう。

実行コマンド
（Dockerコンテナ内にいる場合）

/var/www/html

$ exit

（現在のディレクトリが~/project-root/srcであることを確認してから）

~/project-root/src

$ git add .

コミット

~/project-root/src

$ git commit -m "Set up Inertia with Breeze"

プッシュ

~/project-root/src

$ git push -u origin feature/01-setup-inertia

GitHubのBranchesを見ると、新しいfeature/01-setup-inertiaというブランチが作成されていることが確認できます。

プルリクエストを作成・マージ

リポジトリのトップ画面に戻ると、以下のようにCompare & pull requestという画面が出てくるので、クリックします。

クリックすると、次のような画面が出てきます。

これは、何かというと、プルリクエストの作成画面です。

プルリクエストというのは、GitHubにあるリモートリポジトリ内のブランチをマージ（平行世界の統合）したいという要求を作ることです。
「要求？」って感じだと思います。僕も最初は意味が分かりませんでした。
しかし、それは当然です。普通は会社などで複数人で開発作業をするからです。

前回の説明風に言うとマージは平行世界の統合です。
実は、平行世界を作って移動できる能力を持った人間はあなた以外にもいます。
それが、同じプロジェクトで働く別のエンジニアであり、同僚かもしれませんし、先輩社員かもしれません。この人たちが好き勝手に分岐する前のおおもとの平行世界に自分が作った平行世界の変更履歴をマージしまくっていると、統制が利かなくなりめちゃくちゃになってしまいます。

そこで、一度、個々の作業者が作ったブランチで加えられた変更をおおもとのブランチに統合するべきかを検討し、許可する役割の人が必要です。
コードレビュアーと呼ばれる人で、通常は経験が豊富な先輩社員や上司の方が担当します。

つまり、僕のような新入りが新しい作業ブランチを切って作業しプッシュし、その後「〇〇機能実装のため~~ファイルを編集したのでレビューをお願いします」みたいなメッセージを添えてプルリクエストを作成します。
それを受けてコードレビュアーの上司が「OK」と言って、プル（変更履歴をとってきてマージ）して完了という流れなわけです。

だから、一人でプルリクエストを作って、プルしてもピンとこないのは当然なのです！（あなたは悪くない!!）

以下のようにしましょう！

注意点としては、「base」の部分はdevelopにすることです（何もしないとおそらく最初はmainになっているかと思います）！
今回は、開発用のdevelopブランチにマージしたいので、変更をお忘れなく！

「title」や「description」は分かりやすければ、何でもよいです。
設定ができたら、「Able to merge」（コンフリクトが起きていない）と表示されていることを確認して、右下の「Create pull request」という緑色のボタンをクリック！

そうしたら、任意でコメントをして、「Merge pull request」をクリック！

「Confirm merge」をクリックします。もし、書き方が変な個所があれば、レビュアーの人が「〇〇の~~行目の書き方が違うのでやり直してください」みたいな感じで「Cancel」を押して却下するので、やり直しって感じだと思います。

できたら、画面やや右上の「Insights」を開いて左側の「Network」をクリックしてみると、これまでのブランチ運用歴が可視化されます。

masterから派生したdevelopから、さらにfeature/01-setup-inertiaが派生して、それが再びdevelopに合流しています。
意図したとおりになっていることが確認できます！
平行世界の樹形図みたいな感じでかっこいいですね！
本来は複数人で作業するので、もっと複雑でカラフルな感じなると思います。

3. 認証機能実装

お疲れ様でした！あと、もう一息です！

新規ブランチ作成

次に、認証機能作成用のfeature/02-authという名前の新規ブランチを切ります。

Ubuntu上でsrcに移動して、以下のコマンドで、現在のブランチを確認しましょう。
実行コマンド

~/project-root/src

$ git branch

実行結果

先ほどのまま何もしていなけば、feature/01-setup-inertianにいると思います。

次のコマンドを実行して、developブランチに移動しましょう。
実行コマンド

~/project-root/src

$ git checkout develop

念のため確認です。
実行コマンド

~/project-root/src

$ git branch

実行結果

移動できています。かなり今更ですが、Ubuntuなどのコマンドラインでは「↑」を押すと一つ前に実行したコマンドが出てくるのでいちいち打たなくて済みます。

さて、developブランチに移動したわけですが、これはfeature/01-setup-inertiaが作成された直前の状態です。すなわち、feature/01-setup-inertiaで加えた変更履歴が反映されていません。したがって、この状態のdevelopから新しく切ったfeature/02-authというブランチで作業して、もしfeature/01-setup-inertiaで編集したファイルと同じファイルを編集してコミット・プッシュしてしまったら、コンフリクトが発生してしまいます...

よって、新しいブランチを切って作業するときは、必ず、派生元のブランチを最新の状態に反映させてからにしましょう！！！！

この意識があれば、個人開発においてコンフリクトの発生をかなり抑制できると思います。

実行するコマンドは以下です！
実行コマンド

~/project-root/src

$ git pull origin develop

かなり丁寧に説明します！

git pull [リモートのリポジトリ名] [リモートのブランチ名]で、今いるブランチに指定したブランチ名に保存されている変更履歴を取り込んで統合することができます。
fetchとmergeを同時にできるという説明もできます。

そして、originというのは、繰り返しになりますが、リモートリポジトリであることを示しているのでした。
したがって、これで今いるローカルのdevelopにリモートのdevelopに保存されている変更履歴（先ほどのfeature/01-setup-inertiaで作業してコミット&プッシュ後にプルリクエストを承認してマージした結果）を取り込むことができます。

これによって、今いるローカルのdevelopから新しいfeature/02-authというブランチを切って作業したのち、コミット&プッシュしてもコンフリクトが発生しないということになります！

developが最新化されたので新しいfeature/02-authというブランチを切って、チェックアウトします。
実行コマンド

~/project-root/src

$ git checkout -b feature/02-auth develop

念のため、確認しましょう。
実行コマンド

~/project-root/src

$ git branch

実行結果

Usersテーブルを確認

これでようやく認証機能の作成作業に入れます。
といっても既述の通りBreezeをインストールしたので、実装は実は終わってます。（笑）

まずは、Usersテーブルを確認しましょう！
MariaDBのコンテナに入ってSQLを書いてもいいのですが、今回はVS Codeの便利な機能を使ってみたいと思います。

VS Codeの画面左側にあるメニューに円柱が三つ積み重なったようなアイコンがあると思います。それがDatabase Clientです。

※初めての方は、Database Clientがインストールされていないかもしれません。
これは、VS Codeのプラグインの一つで、このシリーズでVS Codeを初めて紹介した際に述べましたが、便利な拡張機能を追加して自分好みにカスタマイズできるというあれです。

詳しいやり方は、以下の記事を参考にしてみてください。
VSCodeで拡張機能・プラグインをインストール追加する方法
※ただし、今回入れるのは「Database Client」なので注意してください。

アイコンをクリックして出てくる「DATABESE」の右側にある「+」アイコンをクリックすると、以下のような画面が出てきます。

「Host」や「Port」はそのままで、「UserName」にLaravelの.envファイルに保存されているDB_USERNAMEの値を、「Password」にDB_PASSWORDの値をコピペしましょう。

src/.env

DB_CONNECTION=mysql
DB_HOST=mariadb-lab
DB_PORT=3306
DB_DATABASE=development
DB_USERNAME=admin # ←ここと
DB_PASSWORD=secret # ←ここの値をコピる！

Group名はadminでよいでしょう。

入力出来たら、下の「Connect」を押すと、接続完了！

以下ようにデータベースの中身を見ることができます。
試しに「admin」の中の「development」の中の「users」をクリックしてみましょう。

マイグレーションについて（軽く説明）

ここで疑問に思ったかもしれません。
「Usersテーブルなんて作った覚えないけど？もしかして、Laravelにもとから入っているとか...??」

いい線いってますね！(^_-)-☆
実は環境構築編④~Laravelインストール~で伏線を張っていました。（笑）

そこでは、「php artisan migrateというコマンドを実行するとデータベース接続ができているかを確認できる...けど厳密には違う」みたいな説明をしたと思います。

実は、このコマンドはマイグレーションを実行するコマンドだったのです！
マイグレーションって何？？

マイグレーションとは、データベースの設計図をバージョン管理する仕組みです！
そして、マイグレーションはマイグレーションファイルと言うファイルで管理されます。

例えば、「Usersテーブルを作りなさい」みたいな命令がマイグレーションファイルに書かれていて、マイグレーションを実行すると、Usersテーブルが出来上がるってわけです。

これの何が良いのかという説明をしても今は実感がわかないと思いますので割愛しますが、とにかく便利なのですよ！

※しかし、これまた説明が面倒なのですが、php artisan migrateは初回はLaravelをインストールしたときに自動的に実行されるようです。
よって、前回記事の実行結果の画像では、「Nothing to migrate」となっていたわけです。
もし、Laravelインストール時にマイグレーションが自動で行われなかった場合は、php artisan migrate実行時にUsersテーブルなどを作成するマイグレーション結果が表示されたと思います。

VS Codeでsrc配下のdatabeseフォルダの中のmigrationフォルダを開いて見ると確かに「0001_01_01_000000_create_users_table.php」みたいな感じで、Usersテーブルに関するマイグレーションファイルがあります。

このファイル自体はLaravelに最初から作られている（Usersテーブルはどんなサービスでも作るだろうということで）ため、先ほどのコマンドを実行するだけでUsersテーブル（その他複数のテーブルも）が作られます！

このコマンドが成功するには、データベースに接続していないといけないということで、データベース接続確認のためにLaravelインストール時に実行したというわけでした。

新規登録・ログインしてみる

では、新規登録して、ログインしてみましょう!!
http://localhost/

こちらを開くと、右側になにやら「Login」と「Regiser」というボタンがあるではないですか...!!

※画像のURLが若干違いますが、気にしないでください。

前はなかったのに！？
Breezeをインストールしただけで、できちゃうんです！(^_-)-☆

試しに「Regiser」を押して、新規ユーザー登録をしましょう！
名前とかパスワードは何でもOKです。

※すみません。「Email」は小文字じゃないといけないそうなので、適当に直しておいてください。

ログインできました！

画面右上の「Log Out」を押してみましょう。

ホーム画面に戻りました。

今度は、「Log in」を押してみると...

ログインできました!!やった～～！！

Usersテーブルの方を見てみましょう！
クルクルマークをクリックしてRefresh（更新）すると...

登録した内容が保存されています!!完璧(^_-)-☆

コミット&プッシュ

では、これまでの変更履歴をコミット・プッシュしましょう！

めんどくせーなー。あれ？
...でも何かファイルいじったっけ??

そうです。何もいじっていません。Breezeをインストールするだけで、新規登録・ログイン・ログアウト機能などがすべて実装済みのため、僕は今回何も編集していません！
そのため、念のため一応実行している以下のコマンドは何もしなくてもよいです。(≧◇≦)

お疲れ様でした！

コミット結果

一応

~/project-root/src

$ git add .

~/project-root/src

$ git commit -m "Created the Auth with Breeze, but nothing to commit"

~/project-root/src

$ git push -u origin feature/02-auth

GitHubでプルリクエストを作ろうとしても、変更履歴の差異がないので作ることができません。

4. まとめ・次回予告

いかがでしたでしょうか？
今回も長い記事を最後まで読んでくださって本当にありがとうございました！

今回は、Inertiaをセットアップして、認証機能を実装するためにBreezeをインストールしました。
また、MVCについても簡単に解説しました。

さらに、Gitのブランチ運用の仕方について確認しました。
今回は、最初が大事ということで、かなり丁寧に解説しました。
次回以降は、Gitの操作はさらっと解説する程度にしたいと思いますので、分からなくなったときは、ぜひこの記事に戻ってきてください！

それでは、次回からようやく本格的な実装に入っていきます！！
お楽しみに！！

参考

・VSCodeで拡張機能・プラグインをインストール追加する方法