昨今のWebアプリケーション開発では、フロントエンドとバックエンドを分けて開発することが増えています。フロントエンドはHTML/JavaScript/CSSを用いて、バックエンドではPHPやJava、C#、Ruby、Pythonなどといった言語が利用されます。

こうしたフロントエンド・バックエンドを分けて開発する利点やポイントを紹介します。

過去の技術

ユーザー側のUIとバックエンドのサーバー側とを分けて開発するスタイルは特に目新しいものではありません。かつてはWindowsでいうクラサバ方式であり、WebブラウザであればActiveXやJavaアプレット、Flexなどで実現されてきました。

Windowsのクラサバ方式ではクライアント側にアプリケーションをインストールする必要があり、更新などの手順が煩雑になるのが課題でした（ClickOnceによって自動更新もできるようになりましたが）。JavaアプレットやActiveX、FlexなどはHTML5が隆盛になったり、IEのシェアが低下していく中で使われなくなっています。

Webにおいてはサーバー側でHTMLを生成し、それをWebブラウザでレンダリングするのが一般的でした。かつてはクライアント側のPCスペックは貧弱であり、JavaScriptはとても遅いものでした。また、機能も多くはなかったので、サーバー側で生成したものをレンダリングするだけの方が現実的だったと言えます。

HTML5の台頭

そうした中でHTML5（現在はただのHTML）が登場し、JavaScriptも次第に強化されていきました。XMLHTTPからFetch APIを用いた方式に変更されたり、通信量を減少させることで素早く動作させられるようになっています。

SEO的な観点では弱いとされますが、Webアプリケーションのように認証したり、画面操作の多いものについては特に気にする必要はないでしょう。Googleのクローラーも以前に比べるとJavaScriptを十分に解釈できるようになっています。

フロントエンドとバックエンドを分ける利点

では実際にフロントエンドとバックエンドを分けて開発する利点を見ていきます。

1. 通信量の軽減

バックエンドでHTMLを生成する方法の場合、多くがすべてのHTMLを生成してWebブラウザでレンダリングする方式をとります。これは毎回ヘッダーやフッターなどの情報を送り直すので、通信量が増えてしまいます。対して分離した場合には、バックエンドは画面の差異になる部分（一覧データの続きなど）だけを送信し、フロントエンドではそのデータを解釈して画面に反映します。

最低限のデータを送ることで、通信量を大幅に削減できます。その代わりにフロントエンドでデータや画面を操作宇する必要がありますが、これは次の責任範囲の分離というメリットにつながるでしょう。

2. 責任範囲の分離

まず大きな利点は、責任範囲の分離ができることでしょう。UI/UXについてはフロントエンドで、サーバー側はデータ操作に専念できます。フロントエンドとバックエンドはあらかじめ取り決めた手順に沿ってデータの送受信を行います。この内容さえ決まっていれば、お互いが何をしているかは気にする必要がありません。何か不具合があった時にも、どこが障害ポイントなのかが明確です。

3. 開発体制の分離

次に開発体制の分離が可能です。サーバーサイドでHTMLを生成している場合、サーバーサイドのエンジニアがHTMLの組み込みを行う必要があります。組み込むと言うことは、後で発生する修正についても担当しなければなりません。ちょっとした文言の修正や、DOM構造の変更なども作業する必要があり、エンジニアの負担が大きくなります。

フロントエンドとバックエンドが分かれている場合、フロントエンドの開発体制だけでUIの変更が可能です。バックエンドの開発チームはUIについては気にする必要なく、あらかじめ決めたフォーマット（多くの場合JSON）で出力する仕組みを用意しておくだけで済みます。開発自体並行して進められるようになるので、分ける前と比べて素早く開発が進められるでしょう。

4. リリース・デプロイの分離

開発体制が分かれることで、フロントエンドとバックエンドでそれぞれ本番環境への反映が行えるようになります。バックエンドのデプロイとなるとアプリケーションサーバーの再起動であったり、キャッシュの削除など手順が複雑で時間がかかることが多いでしょう。それに対してフロントエンド側であれば、あらかじめ静的に出力されたものをデプロイするケースが多いです。

ユーザーのインタラクションによって細かく動作を変えたりフロントエンドの場合、総じてデプロイ回数は増えがちです。細かく仮説検証を繰り返し、ユーザーにとって使いやすいUI/UXを実現する上でもフロントエンドとバックエンドの分離は大事です。

5. テストの容易性

UIのテストはとても複雑です。ボタンの有無や、画面に書かれている文字などでテストの成否を見たりしますが、デザイン崩れなどは別途テストが必要です。その点、フロントエンドとバックエンドが分離していれば、バックエンドのテストはとてもシンプルになります。JSONなどは元々システム連携用のフォーマットであり、コンピュータにとって理解しやすいものです。

もちろんフロントエンドのテストは変わらないのですが、全体としてテストしづらいよりはマシでしょう。フロントエンドの場合はユニットテストの他、Seleniumなどを使ってテストを行うのが一般的です。

6. 高い再利用性

昨今ではWebアプリケーション以外でもサーバーにあるデータを利用したいケースは多いでしょう。例えばスマートフォンアプリであったり、システム間連携などが挙げられます。そうした時にバックエンド側でUIを持たないことで、同じ情報を別なデバイス向けに再利用しやすくなります。

バックエンド側でHTMLを出力していた時代には、PC向けとスマートフォン向け、さらにフューチャーフォン向けでUIを出し分けていることさえありました。現在であればレスポンシブデザインも使えますし、JSONで出力された内容をスマートフォンアプリで使い回すこともできるでしょう。

7. 変更が容易

フロントエンドの世界は激しく進化しています。アーキテクチャのトレンド変化は速く、各種フレームワークやライブラリのバージョンアップも激しいです。そうした中でバックエンドとフロントエンドが密な状態で開発を行っていると、途中で載せ替えたり、別なフレームワークの選択が難しくなります。

分離しておくことで、フロントエンドは独自に最適な選択肢をとりやすくなります。万一別なフレームワークに変更する際にも、バックエンドへの影響なしで検討できるでしょう。

8. バックエンドを開発しない選択肢が生まれる

フロントエンドとバックエンドを分けてシステムを構築できるならば、バックエンドは開発せずにBaaS（Backend as a Service）を用いる選択肢が生まれます。バックエンドに求められる機能はある程度決まっており、データの保存や取得、認証、ファイルの保存や取得、メール送信などです。こうした機能を備えたBaaSを導入することで、バックエンドの開発負担をゼロにできます。

私たちの提供するHexabaseもそのBaaSの一つであり、各種Webフロントエンドフレームワークと組み合わせたWebアプリケーション開発が可能です。

フロントエンドとバックエンドを分ける欠点

先述の通り、フロントエンドとバックエンドを分けるというのは昔から行われており、それほど大きな欠点はありません。強いて言えば、以下のような点が挙げられます。

1． 利用言語の増加

利用する技術が増えることで、必要とするプログラマーが増えることでしょう。2022年現在、フロントエンドの開発で使えるプログラミング言語はJavaScript一択です。将来的にWebAssemblyによって別な言語も実用レベルで使えるようになるかも知れませんが、JavaScriptが筆頭の言語であることは疑いようがありません。

そしてバックエンドではサーバー側で動作する各種言語が使われます。JavaScriptで書けるNode.jsやDenoを使うならば、フロントエンドとバックエンドでプログラミング言語を共通化できるでしょう。それ以外のプログラミング言語を選んだ場合、フロントエンド担当とバックエンド担当で役割が完全に分かれてしまうかも知れません。

もちろん、ちょっとしたUIの操作でJavaScriptが使われることがあります。現在、Webサイト（Webアプリケーションではなく）であってもJavaScriptをまったく使わないケースは少ないでしょう。そうした点においては、JavaScriptを使わない選択肢は少ないと言えそうです。

2. 複雑度が増す

バックエンドでHTMLを出力する場合、バックエンドで処理全体を担えます。フロントエンドと分離した場合、データのやりとりにJSONを用いるなど、技術的な複雑度は増すでしょう。本当に小さな、ちょっとしたWebサイトであればフロントエンドとバックエンドを分離する利点は小さいかも知れません。

まとめ

これからWebアプリケーションを開発するならば、フロントエンドとバックエンドはなるべく分離して設計した方が良いでしょう。APIファーストで代表されるようにフロントエンドとバックエンドをつなぐAPIを適切に設計すれば、再利用性の高いシステムが開発できます。

もちろんBaaSを導入することで、フロントエンド開発にリソースを集中させることができます。その際にはぜひHexabaseを導入検討してください！

役に立ったら、記事をシェアしてください