【11章】NextJSでのバックエンド開発演習（後半）の振り返り

はじめに

11章では、BaaS(Backend as a Service)を使用したログイン機能(認証)、ストレージ機能の実装を行なった。

また、コードレビューを受けて useState を useForm に統一したり、useEffect + fetcher を
useSWR に変更した。

Chapter 11 でやったこと

• BaaS で認証(ログイン)を実装

• BaaS でストレージを実装

• コードレビューで useState → useForm に統一

• コードレビューで useEffect + fetcher → useSWR に変更

前半では機能追加について、後半ではレビューでの作り直しについて記述していく。

前半:BaaS で認証とストレージ

認証を自前で作らないという選択

今回は、BaaS として Supabase を使用した。

サインアップ・サインインを自前で作ろうとすると、パスワードをどう保管するか、ログイン状態をどう保持するかまで自分で考えることになる。そのあたりを Supabase に任せた形になった。

恐るべし、Supabase!!

これがモダンな技術の面白いところだなと感じた。特にサインアップ、サインインをコードで書けるのは「やば!」と思った。

ストレージ

今回はブログサイトということもあり、サムネイル画像を保存するために利用した。

画像そのものは Supabase のストレージに置き、DB にはそのパスを保存する形にした。

自前でやるなら画像の置き場所を別で用意することになるが、DB とストレージが同じサービス内にあるので、そのあたりを考えなくて済んだのはありがたかった。

後半:コードレビューで受けた2つの指摘

useState → useForm に統一

レビュー前の時点では、サインイン・サインアップのところを useState で管理していた。バリデーションは、input タグの required を利用していた。

今回混在していたのは、私が全体のコードにおける技術の統一性を考えられていなかったからだと思う。提出に気を取られるばかりに、細かいところへの配慮が足りなかったと感じた。

統一したことで、全体のコードの保守性が上がった。

useEffect + fetcher → useSWR

レビュー前は、fetcher 関数の内容を useEffect で発火させることで API を叩く形のコードになっていた。ローディングの state も持っており、真偽値の変化で表示を切り替えていた。エラーハンドリングは try-catch で行っていた。再取得は、再度 API を叩くという逐次的な処理になっていた。

useSWR を使用することで useState と useEffect が消え、fetcher を内包したカスタムフックとして切り出した。引数は URL とした。そうすることで useEffect を使用していた API の部分のコードが全て置き換わり、管理しやすくなるとともにコードの量が圧倒的に減った。

しかし、そう簡単にはうまく実装できなかった。指定する URL によって、受け取る data の中身が変わるためである。

ここでは具体的なコードは記述しないが、カスタムフック側で受け取った data を定数に代入し、その定数に適切な型を与えることで対応した。

また、意識しなくてよくなったこととしてローディングの state がある。useSWR には標準で
isLoading があるため、管理が楽になった。

2つの指摘に共通していたこと

レビュー前も、想定通りの挙動はしていた。それでもコードの中身は、状態を自分で管理し続ける前提になっていた。そのため、それぞれの API に対して管理用のコードが必要になっていた。

結果として、 state を自分で書く経験ができたことは無駄ではなかったと思う。

始めから useSWR を使えば簡単になることは今ならわかる。でも、その背景を理解した言葉で伝えられるようにはなっていないと思う。

まとめ

モダンな技術を使うことで便利さは上がるのかもしれない。

しかし、そのコードや中身を自分の言葉で説明できるようになるためには、土台となる useState や useEffect を理解しておかないといけないと感じた。