探しものの起点になるのはあくまでローカルであってほしい。ネットワークが遮断されてもローカルだけで情報の在処を検索したいし、ローカルだけで情報の在処を記録したい。

#データを保持する場所 できるだけ依存するサブシステムやミドルウェアを増やしたくない。自分のデータは自分の手の届く範囲に持っておきたい。他の人が同じことをしたいと思った時に、あれこれ導入する必要の無いようにしたい。

• クラウドではGoogleスプレッドシート
• ローカルではlocalhostのCouchDb

#疎結合

• クラウドではGoogle Apps Scriptでできる範囲のことに留める
• ローカルはCouchDbとデザインドキュメントとPythonスクリプト

#ユーザーインターフェース

• メールでの送信
• Google Apps Scriptのウェブページ
• localhostのデザインドキュメント

Google SpreadsheetとGoogle Apps Scriptの組み合わせで、クラウド側でのシステムをつくるとすると、スプレッドシートとデータベースの対応関係が付けられると良い。

スプレッドシートとデータベースの対応関係

カラム名とキーが対応するというところは極めて自然なので、そこから上の階層であるシートとスプレッドシートを対応させようとすると次のようになる。CouchDBではデータベースがドキュメントの集合なので、階層がひとつ足りない。ArangoDBではデータベースの下にコレクションがあり、コレクションがドキュメントの集合なので都合が良い。

クラウド	ローカル
スプレッドシート	データベース
シート	コレクション
カラム名	キー
セルの中身	値

この対応関係を採用すると、シートはコレクションである。 つまりGASがクラウド上のあれこれを監視し、シートに格納する。 スクリプトはオブザーバー。 最新の観察結果だけがシートに格納されると思えば良い。 それをローカルのArangoDBに取り込む。 そのためのAPIはGASのContentServiceで提供される。