クライアントサーバーコンピューティングの復活？

過去数か月の間に開発の世界で私が興味を持ったことの1つは、現代のアプリケーションがサーバーではなくクライアントにより多くのインテリジェンスを配置する方法に戻っていることです。 クライアント/サーバーモデルはもちろん新しいものではありません。これは、従来のアプリケーションが長年にわたって構築されてきた方法であり、リッチクライアントアプリケーションがサーバー側アプリケーションと通信します。 しかし、Web、さらにはWeb 2.0の時代に、焦点はWebアプリケーション（通常はJavaベースのアプリケーションサーバー）にあるインテリジェンスの大部分であり、クライアントはクリックするたびに新しいページが読み込まれるブラウザ。

しかし最近、HTML5、CSS、特にJavaScriptの成熟により、開発者はWebページ自体に真のインテリジェンスと真の処理を導入するようになっています。 特に、最新のWebブラウザー内で完全に実行されるインテリジェントなフロントエンドを簡単に作成できる、さまざまなクライアント側のJavaScriptベースのフレームワークが登場しました。 関係するブラウザーは通常、ChromeやSafariを含むWebkitエンジンに基づくブラウザーですが、ほとんどのアプリはFirefoxおよびInternet Explorerの現在のバージョンでも正常に動作するようです。 必要に応じてサーバーからデータをプルして、動的に変化するより複雑なWebページが作成されます。

特にBackbone.js、Ember.js、Angular.jsの3つのMVCフレームワークが注目を集めているようです。 （MVCはmodel-view-controllerの略です。これは本質的にWebクライアントコンピューティングの背後にあるアーキテクチャです。「js」はJavaScriptの略です。）本質的にこれはすべて、過去10だから、はるかに成熟し、ほぼ標準化されています。 アイデアは、ブラウザーに状態とインテリジェンスを追加し、サーバー側でREST APIを使用してブラウザーを接続することです。

バックボーンは、おそらくこれらのフレームワークの中で最も基本的かつ最小限のものです。 多くの人気サイトでさまざまな範囲で使用されています。 Emberは、Appleが支援したSproutcoreと呼ばれるフレームワークから生まれたもので、デスクトップスタイルのアプリケーションを実行できるように設計されたはるかに包括的なフレームワークです。 多くの場合、Bootstrapで使用されます。Bootstrapは、元々Twitterの従業員によって作成されたHTMLおよびCSSのテンプレートのセットです。 Angularは、その中間のように見えるGoogleの代替手段です。一部の人々は、Emberよりも多少柔軟性があり、少なくとも「意見が少ない」と考えていますが、Backboneよりも包括的です。 （Googleは開発者にAngularを使用してコーディングの品質を改善するように促していますが、内部では実際には異なる独自のフレームワークセットを使用しています。）MicrosoftでもこれらのフレームワークのフックをVisual Studioに追加しています。

これはWebであるため、多数の選択肢があります。 私が最近聞いたより興味深いものの1つは、クライアント側とサーバー側の両方でJavaScriptを使用するように設計されたMeteorです。 しかし、これはまだ非常に早い段階であり、実際のユーザーはまだ知りません。 それまでの間、多くの開発者がNode.jsで遊んでいます。これは、サーバー側のJavaScript実装によく使用されます。

このようなフレームワークの利点は明らかです。 リッチWebクライアントアプリケーションは、すべてがサーバーで実行されるシンクライアントアプリケーションよりも強力であり、より優れたユーザーインターフェイスを提供し、オフライン情報の可能性を提供します。 これらのフレームワークを使用すると、すべてをゼロから構築するよりもはるかに高速にリッチWebクライアントアプリケーションを作成でき、各アプリケーションを中心に開発されているコミュニティを活用できます。

おそらく最も重要なことは、特定のネイティブアプリケーションを記述することなく、さまざまなデバイスに合わせて拡張できるモバイルアプリケーションを作成できることです。 各プラットフォームの特定の機能をより直接的に扱うことができるネイティブアプリについては、まだ十分な議論があります。 ただし、多くの開発者は、特にAdobeが購入し、Apache Cordovaプロジェクトにオープンソース化したオープンソースモバイルフレームワークであるPhoneGapなどと組み合わせて使用​​すると、このようなフレームワークがクロスプラットフォーム開発を劇的にスピードアップできることを発見しました。

もちろん、モバイルには、プロセッサの速度などの独自の制限があり、おそらくもっと重要なのは、接続の速度（場合によっては接続の欠如）です。 Webページでアプリが好きな理由の1つは、多くの場合、Wi-Fiまたは高速接続を介して基本機能をダウンロードし、デザイン全体ではなく、必要なデータのみをダウンロードできることです。 PhoneGapなどのパッケージは、ダウンロードしたアプリにJavaScriptを配置することでこの問題を解決します。

ただし、このようなフレームワークには他の問題もあります。 定義上、クライアント側でより多くのコンピューティングを行うと、単純なサーバーのみのアプリに比べて複雑さが増し、実際、古いクライアントサーバーモデルの欠点のいくつかは戻ります。 開発者は両側で状態を管理する必要があります。 2か所でコードを作成すると、両方の場所でセキュリティに集中する必要があります。 開発チームにはしばしばクライアントで作業する人とサーバーで作業する人がいるため、通信に関する追加の問題が発生します。 一方、クライアントサーバーの古い問題の一部は復活せず、代わりにWebソフトウェアの利点を維持します。 これははるかに標準主導型、コミュニティ主導型の世界であるため、単一のプロプライエタリ環境にそれほど依存していません。 クライアント側とサーバー側の部分を分割することにより、UIではなく処理のみを行う、よりクリーンでシンプルなサーバー側の実装も可能になり、結果として必要なリソースが少なくなります。 ただし、通常はブラウザーがアプリの起動時にサーバーからコードを読み込むため、すべてのクライアントを一度に更新できるという利点があります。

よりインテリジェントなWebクライアントへの動きが明らかになっています。すべての場合ではなく、多くの新しいアプリケーションで。 古いアプリケーションをこのモデルに移行するのははるかに困難ですが、その一部も見られます。 古いクライアント/サーバーモデルではありませんが、近づいています。