ミニマリズム。小さくて、データはvimとsha256sumで完全に管理できる。設定を考えると、ユーザーリストが数十人の小規模な家庭用アプリには合ってると思う。

なんで？ってずっと思ってたけど、結局は著者の選択なんだよね。私たちはそれを二者択一として考えがちだけど、実際にはこれか何もないという選択肢だったのかもしれない。あなたの投稿の二行目が好きなんだけど、比較はどうなの？私の意見では、これが本当に小さい（1k loc未満はすごい）ってことが一番のポイントかも。もしかしたら、オッカムの剃刀に従ってSQLを捨てて、最もシンプルなSQL（SQLite）も完全に無視して、CSVにしたのかも。SQLiteが一番シンプルで埋め込み可能なSQLデータベースだと思ってたから、こんなことを言う日が来るとは思わなかった。ちょっと脱線しちゃったかもしれないけど、SQLiteとPocketbaseのやってることが本当に好きなんだ。SQLiteとユーザごとのデータベースを考えると、このアーキテクチャについて考えるだけで幸せになるよ。SQLiteが大好き！

Pocketbaseにはないものを何をもたらすの？ NIHが主な理由だね。PocketBaseが優れている大きな理由は、機能や貢献が厳しく制限されているからだと思う。みんなにはエコシステムに貢献してほしいな。エコシステムは大きくて成長してるから。

公平に言うと、このプロジェクトは最近書いたブログ記事にリンクされてるから、ほんとに小さな個人的/教育的なプロジェクトなんだ。k8sのAPIサーバーが提供するようなAPIを試してみたくて、カスタムリソースの動的スキーマ、均一なREST APIの生成、明確に定義されたRBACルール、ウォッチ/リアルタイム通知、入場フックでのビジネスロジックのカスタマイズなどを実験したよ。できるだけ小さくしようともしたしね。だから、Pocketbaseや他のものと競争するつもりはないんだ。ただ、似たようなアーキテクチャでミニマムなバックエンドを構築するには何が必要かを見てみたいだけなんだ。「データベース」の選択は、まさにその目標によって決まってる。意図的にインターフェースにしたから、もっと良いデータベースも存在するし、少しのコード変更で接続できるよ。でも、最初はGoの標準ライブラリが提供するものを使ったし、CSVはデバッグが簡単だからね。

なんでハウスシェアに参加せずに、自分の家を買ったり借りたりするの？

TIL！クラウドなしのアプリを作るのが好きで、「エクスポート」ボタンを使ってローカルストレージに依存してる。このアプローチがまさに探してたものだ。ローカルファーストのアプリについて読んだことの多くは、コラボレーション機能のためのデータ同期を解決することを含んでたけど、ローカルの永続性だけが必要ならこんなにシンプルだとは思わなかった。

複数のデバイスやブラウザを使ってる人はどうなるの？ローカルストレージを何年も使ってるけど、特にマルチプレイヤーでは導入が難しくなってるよね。

Chromeがデスクトップとモバイルの両方でFile System Access APIをサポートしている今、バックエンドはまだ必要なのかな？これでローカルDBにアクセスできるようになるのかな？アプリが自分のデバイスにあるDBと直接やり取りできるようになって、デバイス間でDBが同期できるといいな。そうすれば、すべてのデバイスでデータを持っていられるけど、データは常に自分のデバイスの中に留まるからね。もちろん、これはネイティブアプリでやるのは比較的簡単だけど、ブラウザ上で動くWebアプリでもできるといいな。ところで、Chromeはログインしているときにローカルストレージをデバイス間で同期するの？

少なくともAndroidの面では、アプリが自分のストレージターゲットに書き込めるようにしてほしいな。理由は、すでにSyncthing-Forkを使って親Syncディレクトリ（ObsidianやOpenTracksなど）を監視して、バックアップシステムに送ってるから。実際、これによりアプリがローカルファーストになって、ネットワークアクセスなしでも動けるようになるんだ。でも、自動バックアップはできるようにしたい。もしこれをもう少し形式化するものがあれば、開発者もアプリを「自分のネットワークを持ち込む」みたいな感じで作れるかも。もしかしたら、すでに誰かがやってるかもしれないね。

何か例ある？

確かにbcryptが好ましいけど、これはただのシンプルなバックエンドだからね。最初に気になったのは、golangの組み込みSQLiteサポートの代わりにCSVをストレージとして使うことだった。SQLite接続はsqlite://data.dbの接続文字列だけでできるからね。

例に入っているなら、誰かのプロダクションコードに入ることは間違いないね。

他の人が推測しているように、私はGoの標準ライブラリが提供するものに制限したよ。個人的/教育的なプロジェクトだから、k8sのAPIサーバーやさまざまな人気のBaaSに似たアーキテクチャで遊んでみたかっただけなんだ。ローカルホストの外で動かすつもりはなかったから、パスワードのセキュリティやデータベースの選択は気にしてなかったし、標準ライブラリにあるもので「十分良ければ」それでいいと思ってた。もう少し柔軟にしようともしたよ。bcryptを使うには、自分のpennybase.HashPasswd関数を提供すればいいし、SQLiteを使うにはpennybase.DBインターフェースの5つのメソッドを実装すればいい。完璧ではないけど、700行のコードサイズであれば、あまり難しくなくカスタマイズできるはずだよ。

SHA-256のような高速ハッシュはそれにとって悪いの？ 高速ハッシュは、データベースが侵害されたときや、ユーザーが異なるサイトでユニークなパスワードを使えない場合にだけ問題になる。ハッシュが時間がかかるのは、オフライン攻撃のシナリオでユーザーを守るためのもの。自分のCPU時間を彼らのために使っているようなもんだよ。オンライン攻撃の文脈では、攻撃者が毎秒何十億回も試すのを防ぐのは簡単だし、ハッシュ操作を一定の時間かかるように見せることもできる。

振り返ってみると、JSONLの方が開発者として扱いやすかったかも。でもCSVを選んだことは後悔してないよ。DBインターフェースはプラグイン可能だから、必要ならJSONLも使えるし、APIレイヤーでデータストレージ（モデル）とデータ転送オブジェクト（DTO）のフォーマットを分けたかったんだ。実際のデータベースみたいにね。CSVは確かに限界があって脆弱だけど、データ変換や検証の部分がもっと明確になったと思う。

それともSQLite？

標準ライブラリ以外の依存関係はないんじゃないかな。

これ、そんなに安いって言ってるわけじゃないし、料金を取るとも言ってないと思う。クリックしてみたら笑えるかも。ロックイン後にコストが上がる心配はしなくていいと思うよ。

「安く始めて、市場を集めたら、ロックイン後にコストを上げる。」コストと価格の用語の違いを理解しておくと、ビジネスプランを書くときや会計士、CFOとコミュニケーションを取るときに役立つよ。「コスト」は企業が購入する供給品や投入物に対して支払う金額。「価格」はその企業が販売する製品に対して買い手に請求する金額。企業はコストを抑えたいし、高い価格から利益を得る。 （「コストを上げる」と言ったとき、ちょっと考えさせられるね）人々は一般的に自分の生活を企業のようには運営しないから、「コスト」と「価格」が同じように見えがちだけど、上記に加えて、企業にとっての「コスト」は実際の支出の合計を反映していて、「価格」はまだ取引されていないものの広告みたいなもの。「コスト」は会計用語で、総収入 - 総コスト = 総利益。「価格」はマーケティング用語で、1個1ドル、12個で10ドル！ （もちろん、これは理解不能にこじつけることもできるけど、それは「ビジネスコミュニケーション」では避けるべきこと。常にコミュニケーションをスムーズにして、要点に早くたどり着くようにしよう。）

君の主なポイントには同意するよ。PBには削るべき余分な部分がたくさんあるわけじゃないしね。プロジェクトのBDはスコープを厳しく制限してるから、そこが良さの一因だと思う。CSVの件は、なんか学術的な演習みたいに感じるな。SQLiteデータベースをテキストエディタで開けないのはちょっと薄い気がする。多くのツールはテキストエディタより軽量なのに、データベース（どんな形式でも）を「読む」ことが目的になることはあまりないからね。多分、クエリを実行したいんだろうから、まずはCSVをDuckDBにインポートして、「WHERE active=1」でいろいろクエリを書いてみるのがいいと思うよ。

Pocketbase以外の候補は何かある？

2025年に、CSVが「小さい」からデータベースの合理的な代替になるって思うのは、ちょっとおかしいよね。全くもって信じられない。

FTS5を有効にしたwasmビルドのSQLiteをデプロイしたばかりなんだけど、これがすごいんだ。基本的にクライアントサイドのElasticsearchみたいなもんだよ。ESほど堅牢ではないけど、80%くらいはそれに近い。繰り返すけど、これはあなたのスマホやSQLite対応のデバイスで動くからね。

ローカルでの使用ケースには役立つかも。ローカルで動かして、自分のやりたいことをやる。Excelや好きなツールで編集する。依存関係も一つ減るしね。

スクリプトから連結できて、スプレッドシートで編集やクエリもできる、テキストのCSVフォーマットっていいよね。メモリ内ポインタキャッシュのおかげで速いし、ターゲットスケーリングのカテゴリにいるなら、大きな利点だと思う。