Poor Man's Back End-as-a-Service (BaaS), Similar to Firebase/Supabase/Pocketbase

Original Article ↗ Hacker News Discussion ↗

Project goals and positioning

  • Seen as an extremely minimal backend in the Firebase/Supabase/Pocketbase space, with ~700–1,000 LOC and human-editable data.
  • Author clarifies it’s a personal/educational experiment, inspired by Kubernetes-style APIs (dynamic schemas, uniform REST, RBAC, watches, admission hooks), not a competitor to Pocketbase.
  • Emphasis on “stdlib only”: no external dependencies, everything manageable with a text editor and standard CLI tools.

Minimalism and storage choices (CSV vs databases)

  • Main differentiator: data in CSV files rather than SQLite or Postgres; users and roles are also stored in _users.csv.
  • Supporters like the debuggability, diffability, ease of backup, and fit with git and spreadsheets; fine for tiny, household-scale apps or static-site build inputs.
  • Critics find CSV fragile and ambiguous, especially compared to JSONL, SQLite, or DuckDB; concerns about corruption and lack of querying/indexing.
  • Some argue CSV is essentially “SQLite with fewer features”; others counter that for very small CRUD apps CSV is perfectly adequate.
  • Even the author notes JSONL might have been easier, but CSV made conversion/validation more explicit and is swappable via a DB interface.

Comparison with existing BaaS / frameworks

  • Many ask why not contribute to Pocketbase, which is already seen as a “poor man’s BaaS” and aggressively minimal.
  • Others suggest just using mature frameworks (Rails, Django, Laravel, Spring) or self-hosted tools like Convex.
  • Some confusion and light pushback around the “BaaS” acronym and title.

Security and password handling

  • Example uses SHA‑256 + salt for passwords, raising concerns since fast hashes are weak under offline compromise; bcrypt or PBKDF2 are recommended.
  • Author reiterates this is a localhost toy; security and database choice were not priorities, but both hash function and DB are pluggable.
  • Brief side debate on whether slow password hashing is worth its cost and carbon footprint, versus enforcing strong random API keys.

Local-first / no-backend alternatives

  • Parallel thread asks whether we need backends at all given Chrome’s File System Access API and browser storage (IndexedDB, localStorage).
  • People discuss fully local apps, syncing via cloud drives or Syncthing, and browser extension storage (chrome.storage.sync) with its limits.
  • General theme: for very small apps, both pennybase-style micro backends and pure local-first approaches are appealing.