1. はじめに
今回は、Honoとクリーンアーキテクチャを学ぶことを目的としてAPIを作成しました。
↓作ったAPIのリポジトリ
2. 何を作ったか
APIの概要
種族値の合計が600以上の第一世代のポケモンを返すAPIです。
600以上をハイスタッツと定義していて、ポケモンのデータ自体はPokeAPIから取得しています。
実際のリクエスト、レスポンス
curl localhost:3000/high-stat
[
{
"id":149,
"name":"dragonite",
"total_stat":600
},
{
"id":150,
"name":"mewtwo",
"total_stat":680
},
{
"id":151,
"name":"mew",
"total_stat":600
}
]
種族値600以上のポケモンが取得できていることがわかります。第一世代で600以上は最後の3匹だけなんですね。
技術スタック
- Hono
- TypeScript
- Vitest
- PokeAPI
3. Honoを使ってみた感想
セットアップの手軽さ
サーバーサイドのフレームワークはFastAPIしか使ったことがなかったのですが、FastAPIに比べるとセットアップが簡単でした。
npm create hono@latestしたらすぐにHello Hono!のエンドポイントを叩けるようになっていて、開発しやすかったです。
気に入った点
HonoはTypeScriptなので、Reactを勉強していた自分からしたら新しく学ぶことも少なく、楽に感じました。
また、今回PokeAPIを使用していますが、以前ReactでPokeAPIを使った開発をしたことがあったため、型を流用することができました。
同じ言語であることでここまで開発効率が上がることに驚きました。今後サーバーサイドはHonoで実装することが多くなりそうです。
4. クリーンアーキテクチャでやってみた
良かったこと
- レイヤーごとの役割が明確
どこに何を書けばいいかがしっかりと決まっていたので、迷うことなく開発できました。
- ゴールから開発できる
ビジネスルールから開発していくので外部APIとか途中の処理とかを考えずに本来の目的に集中することができました。
今までの自分のやり方だと途中の処理に意識を持っていかれて、本来何がやりたかったかがわからなくなり、迷子になることがありました。それで間違った方向に進んで、やり直すみたいなことが過去にありました。
大変だったこと
- 開発手順が曖昧
各レイヤーにどういう役割があって、どういうことを書けばいいのかは概ね理解できたものの、実際に開発してみるとどういう手順で書いていけばいいのかがよくわかりませんでした。
ドメインは書いたけど、ユースケースはどこまで書いて、どのタイミングでテストをするのかとか。
まずはテストが落ちるようにユースケースを書くというのはわかっているがどの完成度で落とすのかがわからず、テスト駆動の意味をなしているのか怪しかったです。
5. PokeAPIを叩いてみて
-
151匹取得するのが不便
PokeAPIには単体取得と複数取得のエンドポイントがあるのですが、種族値は前者にしか含まれていません。なので、取得したいポケモンの数だけfetchする必要がありました。
今回はforで一つひとつfetchしたので、処理が結構遅くなってしまいました。Promise.allで並列処理するやり方に変えようと思います。 -
レスポンスの構造が複雑
以下は単体取得した時の種族値の型です。（一部抜粋）
stats: {
base_stat: number;
effort: number;
stat: {
name: string;
url: string;
};
}[];
statsが配列になっていて、順番にHP、こうげき、ぼうぎょ、とくこう、とくぼう、すばやさの情報が入っています。具体的な値はbase_statです。
初めてPokeAPIを使った時はレスポンスの型を理解するのに時間がかかりました。
6. 学び・気づき
レイヤーごとの役割が明確だから迷いがへる
実装時にどこに何を書こう、と悩む時間がなくなると思いました。
ビジネスルールを先に書くので、目的を見失いにくい
一番の目的を先に決めるので、実装途中で「あれ、なんか何がしたいのかわからなくなってきた」「目的とズレたことしてたからやり直さなきゃ」みたいなのがなくなると思います。
とはいえ、この規模だとあまりメリットを感じない
上の二つのメリットに気づいたものの、今回の規模だとクリーンアーキテクチャの良さを感じづらかったです。PokeAPIのレスポンスが変わったり、別のAPIに変更したりすれば保守性の高さを実感できるはずです。
なので、今度適当にDBとか作成してそこから取得するようなdriverを作成してみようと思います。
7. おわりに
大まかにクリーンアーキテクチャについて理解することができました。実際にアプリでどのようにクリーンアーキテクチャの考え方が使われているのか見てみたくなりました。
また、毎回のように感じることですが、新しいことを学ぼうと思ったら
最小限のインプット → 新しいことを少しだけ取り入れたアウトプット
がやはり一番効率良いです。
今までいきなりすごいアプリを作ろうとしていてわからなくなって挫折していた自分が、段階的なアウトプットに変えたら学習効率が明確に向上しました。
