書籍管理アプリをAppSheetで作る - AppSheetアプリのアーキテクチャ
aromariousこのアプリの構成
書籍のバーコードをスキャンして書籍一覧を作成するアプリをAppSheetで作った。
全体の構成を図にするとこう。
順序はこんな感じ。
このアーキテクチャはちょっと気持ち悪いな、と思いながら作った。
aromariousAppSheetアプリのアーキテクチャ
AppSheetでアプリを作る時の手順はこうだ。
- スキーマを準備する
- それをAppSheetに入力して、CRUDのUIを自動生成してもらう
- できたUIをもとにカスタマイズする
自動生成の直後、初期状態はこうなっている。
このアーキテクチャに従って作る。
UIが直接データストアにアクセスするのはおかしい
AppSheetを触る前は、「AppSheetはフロントエンドを受け持って、複雑なことをする場合にGASでバックエンドを実装するのだろう」と思っていた。だから実際に触ってみて、UIがデータアクセスを受け持っているように見えて違和感があった。UIが直接データストアを触りに行くように見えたからだ。
しかし、触っているうちに、そうではないのかもしれない、と思うようになった。
Webhookを呼び出す、GASの関数を呼び出す、そこをバックエンドと認識するから気持ち悪くなってしまうのだ。バックエンドはネットワークの向こうにあってfetchするものだという固定観念があったが、そうではないな、と認識を改めた。
AppSheetアプリが受け持つレイヤ
AppSheetアプリは大まかにいって次の4つの要素から構成されている。
- Data
- View
- Action
- Bot
Data でデータスキーマを定義する。Viewで画面UIの定義をする。
ActionでViewに配置されるボタンを定義する。Actionはイベントを発生させる。Botは「このイベントが発生したらこの処理をする」を定義する。
各構成要素の役割はこうだろう。
- Data ここの定義に従ってデータアクセス層が動く
- View ここの定義に従ってプレゼンテーション層が動く
- Action プレゼンテーション層からビジネスロジック層への接続（プレゼンテーション層の一部）
- Bot この中に定義する「Process」にビジネスロジックを定義する。Botは「イベント→Process」の定義であり、Actionで開始されたレイヤー間接続を引き継いでビジネスロジックを動作させるための定義
AppSheet全体をひとかたまりで見るから違和感があったのだった。構成要素の役割を見てみれば納得がある。
生成直後の初期状態を図にするとこう。
三層モデルで言えばこうなるだろう。
今回のアプリの構成はつまり、こう。
スッキリした。
次▶️ 書誌情報の再取得を実装した記録