本記事は、Uzabase Advent Calendar 2021 5日目の記事です。

はじめに

2021年11月24日に「【Next.js Update!】v12リリースを踏まえ、Next.jsの採用を考える」に登壇しました。

この記事は登壇した内容を振り返って補足していきます。
登壇した内容と被る部分はスキップさせていただきますので気になる方はYoutubeのアーカイブを是非ご覧になってください。

Next.jsを採用した理由

今回 Next.jsを採用した理由 は大きく3つです。

- Reactベース
- 素早く始められる
- API Routes

特に API Routes を採用したけど、やめた理由について補足します。

API Routesをやめた理由

当初API Routesを BFFとして使う ことを想定してアーキテクチャーを考えました。
個人開発でもNext.jsを採用することが多いですが、その際にBFFとしてAPI Routes採用することが多かったので少し自信はありましたが、いくつか罠がありました。

個人開発では考慮してなかった部分が２つあります。

アプリケーションの規模
フロントエンドもBFFもClean Architecture、DDDを採用

問題点

上記の２つの問題点は問題意識を共有します。
BFFとしてAPI Routesを使うということは、結局 同じパッケージに２つのアプリケーション（フロント・BFF）のソースが入っている ことになります。
アプリケーションの規模が大きく、拡張し続けることが見えているのにその２つを同じパッケージで管理することは良いのかと思いました。

また、ソース管理だけならまだしも同じパッケージにあることで起こり得る問題は ドメインが混ざる ことでした。
Clean Architecture・DDDの構成でやはり大事なことは ドメインと中心において、いかにドメインを守るか だと思います。フロントエンドとBFFはすごく近いし、扱う概念は似ていますが、消して ドメインが一緒 とは言えません。
また、近い関係とはいえ別のアプリケーションとも言える２つのドメインやソースコードが混ざることは避けるべきだと考えます。

もちろんTypeScriptなので意識すれば問題ないかもしれないし、multi-packagingなど、何か解決策はあるかもしれませんが、それらはアプリにとって 無駄な複雑性 になると思い、素直に分けることにしました。

Clean ArchitectureとDDDを採用した理由

フロントエンドでこのようなアーキテクチャーを採用した理由は動画でも触れていますが、反面懸念点もありました。
Clean Architectureはレイヤードの構成で、依存性の逆転など実現のためにはいくつか守るべきポイントがあります。
その際に こんな構成をしてしまうとパフォーマンス落ちるのでは？ とも思ってました。

しかし、パフォーマンス的な懸念をあったにも関わらず採用した理由もあります。品質です。

品質を担保する

アプリケーションを開発して、規模が大きくなるに伴って ロジックが複雑や、 テストが書きにくい とか 書き方が違っててどこに何を書けば良いか分からない などのことに遭遇したことはないでしょうか？
もちろん全くないかも知れませんが、その時のメンバーや状況によって技術的な負債が溜まることはあると思います。

これらの技術的な負債が溜まって開発のスピードが下がることを 品質が低い と言えます。言い換えると 保守性が高くない とも言えます。
フロントエンドでも上記の改題間はもちろんあると思っていて、アプリケーションが大きくなるに伴い品質の低下による開発スピードの低下は加速します。

このような 品質を担保し、保守性高く開発をするための一つとして Clean ArchitectureとDDDを採用 しました。

パフォーマンスはどうする？

もちろん普通の構成よりClean Architecture・DDDのだとパフォーマンスは落ちるかも知れませんが、それが　 ユーザーの体験を損なう レベルではないです。また、Next.jsではパフォーマンス改善の様々な工夫もできるので描画スピードの改善などは違う方法でも測れるとも考えています。

それに個人的には パフォーマンスと品質はトレードオフではない と思っています。
これは凄く難しいことですが、両方を目指すべきで、どっちかのために片方を捨てないといけないわけではないです。

最後に

偉そうに色々書いてますが、実際やってみて これは本当に正解なのか？ の疑問はありました。
フロントエンドでClean Architecture・DDDを採用することは必ず正解ではない と思います。
フロントエンドでこの構成はそこまで多くないし、そもそもアーキテクチャーに正解なんてないですよね。

私たちは今回やってみて良いところも伸び代も感じたので必ずこれにするよりかはチームの状況に合わせて決めることが大事だと思います。

ただ、フロントエンドを立ち上げる際にClean ArchitectureとDDDも選択肢に入れていただければ幸いです。

参考リンク

Youtubeのアーカイブ - Next.jsでClean ArchitectureとDDD
登壇スライド - Next.jsでClean ArchitectureとDDD