フロントエンドとバックエンドを分けた開発について
はじめに
私は今までに様々な言語・フレームワークでバックエンドをメインに開発をしてきました。
その中で、フロントエンドとバックエンドを分けた開発も、分けていない開発も経験しています。
では、分けた時のメリット・デメリットはどんなものがあるのか？を今回記事にしようかと思います。
今まで経験した構成
ざっと、今まで経験したことがあるフロント・バックエンドの構成を表にします。
フロント・バックエンドを分けない構成
※フロントはテンプレートエンジン+jQueryがメインです
| バックエンド | フロントエンド | 備考 |
|---|---|---|
| Laravel | blade | |
| Ruby on Rails | ERB | 部分的にReact |
| ASP.NET(C#) | Razor, Web Forms | MVC, Web Formsどちらも触りました |
| Sprint Boot | Thymeleaf |
フロント・バックエンドを分けた構成
| バックエンド | フロントエンド | 備考 |
|---|---|---|
| Ruby on Rails(API Mode) | React(SPA) | TypeScript, MUI |
| Ruby on Rails(API Mode) | Next.js | TypeScript |
| Express(Node.js) | Next.js | TypeScript, MUI |
昔Vue.jsを趣味と副業で若干触ったことがありますが、業務利用となるとほとんどがReactベースなので今回のお話はReact中心になります。
フロント・バックエンドを分けるメリット
役割分担と専門化
フロントエンドエンジニアとバックエンドエンジニアそれぞれの領域に集中できるため、効率が向上します。
柔軟性と再利用性
フロントエンドとバックエンドが独立しているため、柔軟に変更でき、再利用性が高まります。
例えば、異なるフロントエンドを同じバックエンドに接続できることがあります。
→WebはNext.js, モバイルはFlutterアプリとか。
また、外部サービスにAPIを提供するようなことも可能になります。
同時開発と効率向上
フロントエンドとバックエンドの開発は同時に進めることができ、それぞれの開発者がお互いの進捗に依存することなく効率的に作業できます。
→バックエンドでAPIを開発している最中にフロントは事前に取り決めたAPIのモックで開発するとか。
リリース・デプロイの分離
開発体制が分かれるため、先にバックエンドだけ本番公開してもフロントではまだ使用されないので、分けてデプロイすることが可能になります。
→逆に分離していないと、バックエンドとフロントどちらも準備が整って初めてデプロイする必要があります。
ユーザーエクスペリエンスの向上
フロントエンドがユーザーインターフェースに特化できるため、ユーザーエクスペリエンスを重視した設計や機能の追加が容易になります。
テストの責務分割
フロントとバックエンドを分けることでテストも分離して考えることができるようになります。
バックエンドはAPIのリクエスト・レスポンスを中心に考えることができるので、HTMLの要素についてはテストが不要になります。
フロントはUIのテストに特化することが可能になるため、コンポーネント単位でテストを作成することも可能になります。
※もちろん、どちらも接続した時のテスト観点も必要になりますが(E2Eテストとか)
フロント・バックエンドを分けるデメリット
コミュニケーションの課題が発生する
分けない場合はどちらも同じチーム(同じ担当者)で開発することになりますが、フロントとバックエンドでそれぞれ開発することになるのでAPIの取り決めや仕様についての擦り合わせが必要になります。
統合テストの複雑さ
メリットの方で軽く触れた、一貫したテストについての課題が発生します。
E2Eテスト/シナリオテストの実施など、一貫したテストを行うことで品質を担保する必要があります。
開発全体の進捗管理の難しさ
フロントエンドとバックエンドが別々に進むため、全体の進捗管理が難しくなり、プロジェクト全体の遅延が生じる可能性があります。
初期のセットアップコストの増加
両方の開発環境を構築し、連携させるために初期のセットアップコストが増加する可能性があります。
→Dockerを使ったり、セットアップスクリプトを用意するような自動化で対策可能なので、そういった工夫が必要になります
通信コストと遅延
フロントエンドとバックエンドが異なる場所に存在する場合、通信の遅延が発生し、パフォーマンスが低下する可能性があります。
→CDNの利用やSWRのようなキャッシュを利用した通信回数の削減や、バックエンドではロードバランシングを行うような工夫が必要になります。
個人的な感想
どちらの開発も経験してみて、個人的な感想を記載させていただきます。
小規模チーム(基本的には1チーム)でバックエンドの経験がメインのメンバー中心で開発している場合、フロントとバックエンドを無理に分けなくても良いと思います。
理由としてはチーム全体の学習コストがかかるのと、機能単位での開発で行うことが多いチーム体制になることが経験上多いので、特にスタートアップにおいては事業とチームの状況に応じて判断すべきかと考えます。
逆に大規模なチーム(複数チーム)でフロントの経験もそれなりにある場合は迷わずフロントとバックエンドを分けた方が良いと思います。
将来を見据えると、人が増えてきた時やサービスの拡大に応じてフロントとバックエンドを分ける構成に寄せていく方が上記で述べたようなメリットがあるので、個人的には分けない開発であってもある程度今後のことは念頭に入れておいた方が良いかと思います。
まとめ
今回はフロントとバックエンドを分けるメリット・デメリットについて解説しました。
双方事業やチームの状況に応じて選定するポイントがあると思いますので、「必ずしもこっちだ！！」と言うよりは一度自分たちの状況を再認識してから選定することが重要かと思います。
最後までありがとうございました！
参考記事
※ChatGPT先生との壁打ちもしています
Discussion