動的Webアプリは考えることだらけ

ローカルで動くアプリをWebから使える形にする挑戦は、静的なアプリで一度経験していました。画面や決まった情報を見せるアプリは、苦労しながらも公開までたどり着けました。そこで私は、次はRaspberry Piの状態や蓄積した記録を扱う動的なアプリも同じように進められるのでは、と考えます。しかし実際には、表示する内容がその場で変わるだけで、考えることが一気に増えました。

Raspberry Piの状態を見るアプリでは、Web側に画面を置くだけでは現在の状態が分かりません。Webから問い合わせが来た時に、Raspberry Pi側で状態を確認して返す役が必要です。そのため、Raspberry Piで動き続ける常駐エージェントを用意することになりました。私はCodexに示された手順を追い、ターミナルを操作しながら、状態を安全に返せる形を何度も試します。

気温やCPU温度の記録を残すセンサーヒストリーアプリには、また別の課題がありました。データはGitHubへバックアップしているため、Web側で使うにはGitHubのワークフローも新しく整える必要があります。同じWebアプリ化でも、現在の状態を取りに行くアプリと、蓄積した記録を運ぶアプリでは、必要な通り道が違うのだと分かりました。

漫画のセリフを編集するアプリでは、画像をクラウドへ保存する場所が必要になります。そこでCloudflareのオブジェクトストレージを使うことになりました。ローカルなら手元のファイルへ自由に置けた画像も、Webではどこに保存し、アプリからどう扱うかを決めなければなりません。私の机の上だけで完結していたものが、複数のサービスへ広がっていきます。

さらに気になったのが、使うデータ量と課金枠です。便利だからと保存や通信を増やせば、使い方によっては有料の範囲に入る可能性があります。私は新しい機能が動く喜びと同時に、使用量のメーターを恐る恐る見ることになりました。安全面や公開範囲に加え、どのデータをどれだけ扱うのかも、Webアプリでは無視できない設計の一部です。

ローカルアプリは、自分のRaspberry Piの中で好きな形に組み立てられました。Webアプリになると、常駐エージェント、ワークフロー、保存先などを目的に合わせて組み合わせ、その間の流れと費用も考える必要があります。私は難しさに圧倒されつつも、動的アプリごとの違いを一つずつ学びました。次は実際の使用量を見ながら、必要なデータと仕組みを整理していく番です。