サーバサイドで機能を実装する利点
ある機能を実装する際に、サーバサイドでもフロントエンドでも作れる場合は多々あります。しかし、機能面よりも、環境の違い、もしくは制限を意識しなければいけないのがセキュリティです。
同じ機能をフロントエンドで実現する場合、サーバサイドで開発する場合に比べてセキュリティ上で考慮すべき点が多くなります。そして、考慮すべき点が多くなれば多くなるほど、開発は複雑になります。つまり、できるだけ機能をシンプルに作るならば、サーバサイドで機能を実装する方が考慮すべき点が少なくなります。
サーバサイドでは図2のようなネットワーク構造を構築し、そこにそれぞれの役割に応じたシステムを構築します。
まず、公開ネットワークではインターネットからのアクセスを担当します。つまり、信用できない相手と通信しなければならないため、公開ネットワークでできることは非常に貧弱です。例えばWebサーバがHTMLなどのWebコンテンツを返す機能を持ちます。そのため、この公開ネットワークが誰かに乗っ取られても、重要な情報が流出するリスクは理論上はありません。
そして、その下にあるのがDMZ（非武装地帯）で、簡単に言えば公開ネットワークからも、内部ネットワークからも信頼できるアクセス元です。ここは、公開ネットワークから来るリクエストを元に、内部ネットワークにアクセスして必要な情報や機能を提供する役割があります。そして、内部ネットワークはなんら制限がない領域で、多くのWebシステムではここにデータベースを配置します。
このような構造にすることで役割に応じた効率化が行いやすく、また、設計・開発において以下のようなメリットが生じます。
（1）機能を実装するための前提条件を自由に設計できる
「前提条件を自由に設計できる」とは、自由な実装を許す反面、結果的により煩雑になってしまう懸念もあるでしょう。確かに、Web創生期には、そういった傾向がありました。
しかし、サーバサイド技術はさまざまな目的別のフレームワークが誕生する方向で進化しました。
例えば、JavaのTomcatやWebSphere、Ruby on Rails、PHPであればLaravel、PythonのDjangoなど、ここでは紹介しきれないほどの多様なフレームワークが生まれました。開発者は自分の使い勝手や目的にあったフレームワークを選ぶことで、大幅に開発を効率化できます。
また、WebサイトやブログサイトであればWordPress、ECシステムであればMagento、全文検索であればApache Solrといった、より目的に特化したカスタマイズ可能なソフトウェアも生まれました。こういったフレームワークやカスタマイズを前提としたソフトウェアの存在は、開発者に大きな力を与えてくれました。
これらのフレームワークは強力なルールも同時に課し、開発者はそのルールを守って開発を進めることで、効率よく開発が進められました。
（2）外部要因の直接的な影響を回避できる場合が多い
これは、例えばOSのバージョンアップを指します。OSのバージョンアップはセキュリティ対応を含みますが、既存システムへの影響は避けられません。
そのため、既存のシステムが同じように動くことを確認したり、影響を考慮して細かい修正対応をしたりといった作業が生じてしまいます。特にオリジナルのシステムでは他の事例を参考にできないため、できればやりたくない作業でしょう。
このとき、ネットワークとして制限されているため、想定外の利用に対するリスク対策を自分たちの都合に合わせて行う、もしくは対応しないという判断すらできます。
この「バージョンアップ作業を必ずしも行わなくていい」というメリットは、技術の延命にも役立ちます。つまり、同じ技術の利用時間が長いということは、手法の再利用やノウハウの継承などが行いやすいことにもつながります。
最適化の方向性の違い
「効率」を考えたときに、最適化をする際の方向性としても、以下のような考え方があります。
- 人を中心とした最適化
- 仕組み（ルール）を中心とした最適化
また、これらの特徴を表したのが図3です。
左側の図はサーバサイドの考え方をした場合の最適化の方法、右側が現在のフロントエンド技術を使った場合の最適化の方法です。この違いは利用する技術によって生じるのではなく、むしろ、最適化したい方向性に合わせて、技術側が進化していったと捉えるべきでしょう。
先ほど説明した通り、サーバサイドでは多様な環境が受け入れやすい傾向があります。そして、時代とともに実現したいことが多様化するにつれて、その手法も多様化していきました。
一方、そうした多様化も時間や経験と共に定型化されます。先ほど記したWebフレームワークなどはまさしく、この定型化による最適化を目的としたツールです。このような工程から開発する一人ひとりにとっての多様性は必要なくなり、それぞれの専門性とそれぞれの手順の最適化が容易になります。
もちろん、仕組みを中心に考えた効率化の側面は、フロントエンドにも見られます。これまでの最適化のルールを大きく変えるきっかけになったのが、スマホアプリとNode.jsというサーバサイドで動くJavaScript実行環境です。スマホアプリはそれ自体で機能が完結でき、Node.jsによりクライアント技術をそのままサーバ側に持ち込むことが可能になりました。
すべての機能を単一言語で実装できれば、おのずと境界線は曖昧になります。結果として一人の開発者が実現すべき機能は非常に多岐にわたることになります。
結果、サーバサイドで存在した厳密なルールは、メリットよりもデメリットの方が大きくなります。こういった環境下では「人を中心とした最適化」を促進することになります。
例えば、Next.jsというJavaScript（React）のフレームワークを使ってWebシステムを作った場合を見ると、この特徴がよくわかります。
図4は1つのソースコードに、サーバ側で動く機能、クライアント側で動く機能、HTMLやデザインが含まれる形を表した図です。
こういった環境では、ソースコードを役割に応じて分けるのではなく、利用者視点の機能で区分することになります。手段や関連するリソース（CSSなど）をできるだけまとめ、担当する開発者が管理しやすいレベルにパッケージング化していくわけです。その結果として、一見複雑な構造をもつコード形式が生まれました。
ただし、先ほどの図は少々意地悪な見方であり、図5のように利用者から見た場合、むしろ分かりやすい構造になっているとも言えます。
このように、HTML5以前のサーバサイド技術を中心に据えたWebシステムは、それぞれの技術的役割を中心にした最適化がしやすく、HTML5以降のフロントエンド技術を中心に据えたWebシステムでは人を中心にした最適化がしやすいことになります。
つまり、これらの技術は、そもそも適用する場所や目的が違うとも言えます。
