Live data from Hacker News

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

github.com

71–80 of 135 posts

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

#71
post #4

Do we still need a back-end, now that Chrome supports the File System Access API on both desktop and mobile? I have started writing web apps that simply store the user data as a file, and I am very pleased with this approach. It works perfectly for Desktop and Android. iOS does not allow for real Chrome everywhere (only in Europe, I think), so I also offer to store the data in the "Origin private file system" which a…

At least on the Android front, I'd prefer the app allow me to write to my own storage target. The reason is because I already use Syncthing-Fork to monitor a parent Sync directory of stuff (Obsidian, OpenTracks, etc.) and send to my backup system. In effect it allows apps to be local first and potentially even without network access, but allow me to have automatic backups. If there were something that formalized this…

What do you mean by "storage target"?

Since the File Access API lets web apps simply use the file system, I guess you could just write the file to a shared drive.

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

#72
post #58

Earlier quoted context omitted.

In 2020 Tailscale used a JSON file. https://tailscale.com/blog/an-unlikely-database-migration

If you continue reading, you'll see that they were forced to ditch JSON for a proper key-value database.

I know. Now see how far JSON got them.

So why wouldn't you just use a text format to persist a personal website a handful of people might use?

I created one of the SQLite drivers, but why would you bring in a dependency that might not be available in a decade unless you really need it? (SQLite will be there in 2035, but maybe not the current Go drivers)

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

#73
post #68

Calling this a Poor Man’s backend isn’t even the wrong name for it. Admittedly, this is what I’d expect from a Sophomore in University. To the others arguing you should’ve stored the data as a binary, might as well have created an API wrapper around SQLite at that rate and called it “JASW - Just Another Sqlite Wrapper”. @ OP - what was the inspiration for the project? Were you learning DBs or intending to use this in…

zserge is one of my favorite authors and programmers.

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

#74
post #70
post #14

Earlier quoted context omitted.

What about those of us who use multiple devices, or multiple browsers? I've been using local storage for years and it's definitely hampering adoption, especially for multiplayer.

One approach might be to save the file to a shared drive like Google Drive?

Not sure I trust Dropbox to merge data. What happens when I want to migrate my data structures to a new schema?

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

#76
post #64
post #50

Earlier quoted context omitted.

In 2025, pretending that a CSV can be a reasonable alternative to a database because it is "smaller" is just wild. Totally unconscionable.

I use CSV files to run multiple sites with 40,000+ pages each. Close to 1mil pages total Super fast Can’t hack me because those CSV files are stored elsewhere and only pulled on build Free, ultra fast, no latency. Every alternative I’ve tried is slower and eventually costs money. CSV files stored on GitHub/vercel/netlify/cloudflare pages can scale to millions of rows for free if divided properly

So... SQLite with less features basically.

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

#77
post #52

> Another important file is _users.csv which contains user credentials and roles. It has the same format as other resources, but with a special _users collection name. There is no way to add new users via API, they must be created manually by editing this file: admin,1,salt,5V5R4SO4ZIFMXRZUL2EQMT2CJSREI7EMTK7AH2ND3T7BXIDLMNVQ====,"admin" alice,1,salt,PXHQWNPTZCBORTO5ASIJYVVAINQLQKJSOAQ4UXIAKTR55BU4HGRQ====, > Here we…

> isn't fast hashing like SHA-256 bad for it Fast hashing is only a concern if your database becomes compromised and your users are incapable of using unique passwords on different sites. The hashing taking forever is entirely about protecting users from themselves in the case of an offline attack scenario. You are burning your own CPU time on their behalf. In an online attack context, it is trivial to prevent an att…

Users don’t use unique passwords. Don’t expect them to.

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

#78
post #3

I don't understand why create a new project instead of contributing to Pocketbase, which looks very similar. What does it bring that is not already there in Pocketbase?

Why do you buy/rent your own house instead of joining a house share?

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

#80
post #64

Earlier quoted context omitted.

I use CSV files to run multiple sites with 40,000+ pages each. Close to 1mil pages total Super fast Can’t hack me because those CSV files are stored elsewhere and only pulled on build Free, ultra fast, no latency. Every alternative I’ve tried is slower and eventually costs money. CSV files stored on GitHub/vercel/netlify/cloudflare pages can scale to millions of rows for free if divided properly

So... SQLite with less features basically.

Every file format is SQLite with fewer features.
Post reply on HN