従来のWebアプリケーションでは，フロントエンドとバックエンドは完全にコードが分離しているのが普通でした。そして，フロントエンドとバックエンドでは扱う言語が異なるのも一般的です。フロントエンドではJavaScript，バックエンドではJava，Perl，PHP，Python，Ruby，などの言語を用いていたのです。こうしたフロントエンドとバックエンドの断絶があったことから，両者の間ではコードの共有が行われることはほぼありませんでした。エラーメッセージのような，両者で統一して取り扱うべきリソースを共有するのも一苦労でした。

しかしMeteorでは，サーバもクライアントもJavaScriptで記述するというアーキテクチャを取っていることから，サーバとクライアントの双方で多くのコードを共有することができます。特にMeteorは，クライアントとサーバでできる限り同様のコードが動作するよう考えられたアーキテクチャのため，コードを共有できる範囲は非常に大きく，Webアプリケーション全体のコードも非常にコンパクトになります。

今回は，そうしたMeteorのアーキテクチャを，データベース処理を中心としながら学んでいきたいと思います。データベース処理の詳細については，次回以降に開設します。

Meteorにおけるデータベース処理の考え方

Meteorは，データベース処理に対し，これまでのWebアプリケーションとは全く異なるアプローチを取っています。それは，「⁠サーバ上でデータベースを扱うのと同様のコードを，クライアントでも利用できる」というものです。

そのことを端的に表す例を挙げると，以下のコードはデータベースからデータを一件取得するためのコードですが，これはサーバだけではなく，クライアント上でも動作します。

// 名前が「白石」のデータを取得する
Employees.find({name: '白石'});

なぜこのコードがクライアント上でも動作するのでしょうか？それは，すべてのMeteorクライアントはサーバ上のデータをメモリ上にキャッシュするためです。上記のコードがクライアント上で実行された場合，それはキャッシュに対するデータ取得処理となります。

また，クライアント上でデータを変更した場合はどうなるのでしょうか？その場合には，まずクライアント上のキャッシュが変更され，即座にサーバに対して変更処理がリクエストされます。そして，サーバ上のデータが正常に変更されると，その変更はすべてのMeteorクライアントに伝えられ，全クライアントのキャッシュが変更されることになります（いわば，全クライアントのキャッシュが「同期」されるわけです⁠）⁠。

こうしたアーキテクチャにより，以下に挙げるようなさまざまな利点を得ることができます。

• サーバとクライアントのコードを共通化できる。たとえば，入力データの妥当性を検証したあとにデータベースを更新するようなコードを，サーバとクライアントの双方で利用できます。
• クライアント側では，基本的にキャッシュを対象とした処理となるので，データの取得処理や更新処理が非常に速い。ネットワークの遅延を感じさせることなく，ユーザに素早く処理結果を表示することができます。
• さらに，別のクライアントが行った変更が瞬時に伝わるため，UIのリアルタイム性が非常に高くなります。一般的なWebアプリケーションでは，実現が容易ではないリアルタイムWebアプリケーションを，いとも簡単に実現することができるのです。

Meteorはデフォルトでは，サーバ上のデータすべてをクライアントがキャッシュするようになっています。これは，Meteorを学び始めた開発者にとっての手軽さを優先させているためです。

とはいえ実際には，巨大なサーバデータのすべてをクライアント側にキャッシュすることは現実的ではありません。Meteorのデフォルト動作を変更し，キャッシュするデータを絞り込む方法については，次回以降にお伝えします。