通信の流れ
ソーシャルコンテンツは、一般的にクライアント側（フロントエンド）とサーバー側（バックエンド）に分けられます。
そして、それらが相互に通信を行うことでデータをやり取りしています。
今回はその流れをかみ砕いて紹介していきます。
①クライアント側リクエスト
クライアントとは、私たちのパソコンを指します。
私たちはグーグルで検索した後にでてきた候補をクリックします。
この際、サーバー側に「このURL」のwebページデータを見せてほしいという要求を送っていることになります。
②サーバー側のリクエスト処理
リクエストはサーバー側の各コントローラーに割り振られ、コントローラーはリクエストURLに対して、あらかじめ設定しておいた処理を行います。
このコントローラーを通して、リクエストURLと既定の処理を紐づけることをルーティングといいます。
処理の内容として、基本的には、データベース内にある値を返します。
この際にコントローラーから直接データベースにアクセスして値を回収することも可能なのですが、データベースの値はシンプルすぎて、そのままクライアントに返せないものが多々あります。
例えば、日付の場合は、2020-10-10のかたちで取得されてしまいます。クライアントには、2020年10月10日のかたちで返してあげたほうがわかりやすいですよね。
そこで、データベースとコントローラーの間に入り、データベースの数値をわかりやすい形に変換する必要があります。
そのようなデータベースの数値の管理機能をもたせたものをモデルといいます。
コントローラーがモデル経由で加工した見やすいリクエストの答えを取得します。
③サーバー側の返信
コントローラーが答えとなる数値をそのままクライアントに送るわけではなく、さらにステップを踏みます。
答えのデータはビューという部分に渡されます。
ビューの役割は、データベースから得たデータを最新データとしてHTMLを生成しなおすことにあります。
というのも、ツイッターの書き込みやブログの人気ランキングなどに代表されるリアルタイムの情報をクライアント画面に反映する必要があり、毎回最新情報を提示しなおさないといけないのです。
このような処理を通じて、生成されたHTMLをクライアントに渡すことになります。
④クライアント側はデータ保存して、表示更新
プライバシー問題で下火になったCookieの代わりに、WebStorageを使いローカルディスク上にデータを保存します。
WebStorageにはタブを閉じるまで保存しているsessionStrageと、永続的に保存してくれるlocalStorageがありますので、大抵の場合はlocalStorageとなります。
ただ、単純なデータ構造になっているので、検索作業などには対応できていないようです。
その代わりに複雑な処理はWeb SQL Databaseが使われています。
Web SQL Databaseはブラウザからアクセスできる表型データベースです。
しかし、クライアント側ブラウザによって使用の可否がきまるようなので使い勝手が難しい部分になっています。
