始めに
こんにちは〜まんじです。
今回は主にウェブ開発でフロントエンドとバックエンドを分ける理由について書いていきたいと思います。
いくつか理由はあるんですけど、1番の理由はリッチなUIが作りやすいからじゃね・・・？と個人的には感じているところです。
*サーバーサイド = バックエンド って言葉になります。
ざっくりとした違い
バックエンドのみの構成
Spring, Django, Flask, Expressなどなどのサーバーサイド側のフレームワークだけを使うパターンです。
MPAとか言われます。
この場合は、htmlにテンプレートエンジンとかいう独自の記法{%for item in items%}っぽいやつを使ったりしてサーバーサイドのデータをhtmlに入れて表示します。
全部サーバーサイドでhtmlを作ってそれをクライアント側に戻すので、一般的にレスポンスのスピードが遅くなりがちってのはありますし、リクエストが増えるに伴ってサーバー側で作るhtmlの量が増えます。
このWordPressのサイトもなんですが、別のURLに移動するたびにリロードが発生するのも特徴の1つです。
フロントエンドとバックエンドの構成
- サーバーサイド: ExpressでAPI
- フロントエンド: ReactでCSR(クライアントサイドレンダリング)
主にフロントエンド側にはプレーンな最低限のindex.htmlとUIを作るJavaScriptファイルを送ってクライアント側でUIが作られます。
その際にデータがないので、そのデータをReact側からaxiosなどを使ってサーバーサイド(API)にリクエストして、データが入ってUIが作られます。
この構成にすると、サーバーサイド側でhtmlを作る必要がなくなってクライアント側でJavaScriptが動いて作られることになるので、パフォーマンスは上げやすいです。
あとはReactなどのフロントエンドフレームワークを使うことで、リッチなUIも作りやすかったりSPA（シングルページアプリケーション）も簡単に作れます。
フロントエンドとバックエンドを分けるメリット
メリット面を書いてみます。
リッチなモダンUIを持つアプリケーションが作りやすい
airbnb, メルカリ, Youtube, Tiktokなどのweb版などのイマドキなイケてるアプリケーションは例外なくフロントエンドとバックエンドが分けられてます。
あんな感じのウェブアプリで、ユーザーがなんかアクションを起こしてそれに対してAPI使ってデータを更新したり表示したりをなめらかに行うアプリケーションはフロンとエンドとバックエンドを分けることがほぼ必須です。
フロントエンドフレームワークに対してのUIライブラリなどもReactなどのフロントエンドフレームワークを使うとCSSをがんばって書かなくても簡単にできるんで、そういう意味合いでもフロントエンドフレームワークを使ってバックエンドも用意するっていう構成はごくごく一般的になってきてます。
サーバーサイド側のパフォーマンス的な側面
フロントエンドフレームワークでもNext.jsなどを使うことでサーバーサイドレンダリングができるようにはなってきてはいます。
ただ、基本的にhtmlとデータを組み込んだ生成がフロントエンドとバックエンドを分けることでクライアント側の端末で行えるのでパフォーマンスは良くなる傾向にあります。
スケーラビリティを考慮しやすい
ぶっちゃけ記事を書いてる自分も深くは理解してはいないですけど、マイクロサービスなどの特定の機能や役割ごとにサーバーを分離したりする構成が取りやすいです。
クライント側から複数のエンドポイント（API）に向けてリクエストを分けることもできますし、特定のエンドポイントに向けてリクエストをしてそれをバックエンド側でルーティングするみたいなこともやりやすいです。
同時開発しやすい
フロントエンドとバックエンドのリポジトリが分けられているとしても分けられていないとしても、開発するコードの部分が違くなるので同時に開発は複数人で進めやすいです。
Aという機能を作るために、APIの開発はこの人、フロントエンドのUIはあの人、みたくシンプルにやりやすいです。
フロントエンドとバックエンドを分けるデメリット
デメリットはそこまでないです。
初心者というか入門者の頃はバックエンドもフロントエンドもやらないといけないとか勉強することが増えてつらいって思いがちなんですけど、強いていうなら学習コストぐらい…?
なんですけど、バックエンドだけの構成だとそもそもリッチなUIが作りにくいんで、それはそれでデメリットではあります。
言語が複数になる（？）
バックエンド: GO
フロントエンド: TypeScript
こんな感じに2つの言語になることは珍しくありません。
マイクロサービスのようなアーキテクチャの場合はバックエンドのサービスごとにさらに言語が分けられているケースもあったりします。
こんなんとか。
認証のバックエンド: Java
SNS系の機能: Go
分析機能: Python
EC系の機能: TypeScript
フロントエンド: TypeScript
バックエンドもフロントエンドもTypeScriptでいけるっちゃいけるんですけど、言語を変えるとやりやすいこともあったりするので、なんだかんだでバックエンド側の言語はいろいろ出現しがちです。
工数が増える（？）
バックエンドだけのウェブアプリを作るよりも工数は多分増えます。
ただ実際問題、バックエンド側だけのフレームワークで作ると工数が減ったとしても、実現できる範囲がどうしても狭まりがちってのがあります。
あと、それなりにリッチめなUIにしようとすると、多分バックエンドフレームワークだけでやるほうが工数もかかるし複雑になる可能性が高そうです。
両方に専門的な人が必要になる
バックエンドだけのアプリケーションだと、バックエンドの知識 + html,cssと気合いJavaScriptって感じです。
が、バックエンドとフロントエンドを分ける場合にはそれぞれに専門的な人が必要になるか、両方できる人が必要になります。
基本的には、バックエンドエンジニアと呼ばれる人とフロントエンドエンジニアと呼ばれる人を配置する必要はあります。
ただ、それなりにフロントエンドできる人になるとバックエンドもレベルの違いはあれど開発できるんで、フロントエンドエンジニアの人がまるっとやってしまって、よりバックエンドの深い部分の理解が必要になるとバックエンドの人とフロントエンドの人で協業して開発を進めることにはなりがちです。
複数人で開発する時はコミュニケーションを取る工数が増える(?)
これは別にフロントエンドとバックエンドを分ける場合に限らず、複数人でやることでコミュニケーションコストのようなものはチーム開発をしているとあります。
フロントエンドとバックエンドを分けることで発生するデメリットというよりかは、複数人関わるとコミュニケーションが必要になるってだけです。
まとめ
- リッチなUIが作りやすい
- 責務の分離などがしやすい
- スケーラビリティの考慮
- ぶっちゃけフロントエンドとバックエンドを分ける構成が主流だし技術的に必要だから
この4つらへんがフロントエンドとバックエンドを分ける主な理由かなと個人的に思っているところです。
なんにせよややイマドキっぽいウェブアプリケーションを作るってなるとフロントエンドとバックエンドを分ける構成は必須感が否定できないところなので、とりあえずその構成にのっかるのがおすすめというか、良い感じなのがフロントエンドとバックエンドを分ける理由でした。
