フロントで計算させない設計 ── 4クライアントのロジックをバックエンドに集約した話

割り勘アプリ wa/ri は、iOS / Android / Web / LINE（LIFF）の4プラットフォームに対応している。

クライアントが4つあると、普通に考えれば「同じロジックを4回実装する」か「共通ライブラリを作って各クライアントに持たせる」という方向に進みがちだ。

wa/riではどちらも選ばなかった。割り勘の計算ロジックはすべてバックエンド（NestJS）に集約し、クライアントはAPIを叩くだけという設計にした。

その理由と、実際に運用してみての効果を書く。

クライアント（iOS / Android / Web / LIFF）
        ↓ API呼び出し
バックエンド（NestJS）← ここにロジックが全部ある
        ↓
PostgreSQL（Prisma ORM）

クライアントはUIの描画とAPIとの通信に専念する。計算・精算ロジックはバックエンドが持つ。

割り勘の計算ロジックは、wa/riの場合そこそこ複雑だ。

これを Swift・Dart（Flutter）・場合によってはJavaScript（LIFF）で別々に実装すると、コードが3〜4本に増える。 バグも3〜4箇所に生まれる可能性がある。

ロジックが各クライアントに分散していると、テストも分散する。

同じロジックに対して複数の言語でテストを書くのは、個人開発において現実的ではない。

バグを直すとき、ロジックが各クライアントにあると全クライアントを修正してリリースし直す必要がある。

iOSとAndroidはストア審査がある。審査が通るまで修正が反映されない。Web・LIFFはすぐ反映できても、iOSだけ古い挙動のままになる、という状態が発生しうる。

ロジックがNestJSに集約されているため、バックエンドのテストを通れば全クライアントの正しさが担保される。

wa/riでは計算ロジックをモジュールとして独立させており、そこにテストを集中させている。iOSのコードを触らなくても、Dartのコードを触らなくても、バックエンドのテストがグリーンであれば全クライアントで正しく動く。

バックエンドを直してデプロイすれば、iOS / Android / Web / LIFF のすべてに即反映される。

ストア審査もビルド待ちも不要。個人開発でマルチプラットフォームをやっている身としては、これは実運用でかなり効いている。

クライアントはAPIを叩いてレスポンスを表示するだけでいい。UIロジックと計算ロジックが明確に分離されるため、各クライアントのコードが見通しやすくなる。

正直に言うと、この設計にはデメリットもある。

ロジックがサーバーにあるため、ネットワークがない状態では計算ができない。

wa/riは「友人との割り勘」という用途上、オフラインで使うシーンはほぼないと判断したが、用途によってはこれが致命的になる。

計算のたびにAPIリクエストが発生する。ローカルで完結する計算と比べると、レスポンスに数百ミリ秒の遅延が生じる。

UX上問題にならないレベルに収めるための工夫（ローディング表示、楽観的更新など）は別途必要になる。

チームで開発する場合、クライアントとサーバーを別チームが担当するケースも多い。その場合はクライアント側にある程度ロジックを持たせる方が開発しやすいこともある。

一方、個人開発でマルチプラットフォームをやる場合、この設計は特に有効だ。

この状況で「同じロジックを複数の言語で複数回書く」のは、明らかに持続不可能だ。ロジックを一箇所に集めることで、個人の認知コストと保守コストを大幅に下げられる。

「フロントで計算させない」という設計の本質は、ロジックの責務をどこに置くかを明確にすることだ。

wa/riの場合、それはバックエンドだった。その選択によって、テスト容易性・修正コスト・クライアントのシンプルさという3つの恩恵を同時に得られた。

マルチプラットフォームの個人開発を考えている人に、一つの参考になれば。