Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

41–50 of 135 posts

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

#41

Post by gausswho »

TekMol wrote: 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 a little more, developers could even make their apps in a... Bring Your Own Network... kinda way. Maybe there's already someone doing this?

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

#42

Post by ehutch79 »

fkyoureadthedoc wrote: post #5

> 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…

If it's in the examples, it WILL make it to someone's production code

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

#43

Post by ncruces »

Imustaskforhelp wrote: post #30
jasonthorsness wrote: post #27

Earlier quoted context omitted.

It doesn’t and using the standard 3rd party package requires compiling with CGO which is a pain for cross-platform :(

theoretically there is a go port of sqlite by either using wazero[1] (wasm runtime) and then using sqlite from there or some modernc package[2](i am not sure what this website is except for the sqlite part, so maybe someone can clarify that though) There was also this wrapper of sorts to make the wazero thing genuinely easier to do and it was on r/golang but I don't remember its name but I do think it is semi popular…

For modernc you gave the correct link.

For the wazero based driver, it's this package (I'm the author): https://github.com/ncruces/go-sqlite3

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

#44

Post by zserge »

fkyoureadthedoc wrote: post #5

> 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…

Like others have guessed, I limited myself to what Go stdlib offers. Since it's a personal/educational project -- I only wanted to play around with this sort of architecture (similar to k8s apiserver and various popular BaaSes). It was never meant to run outside of my localhost, so password security or choice of the database was never a concern -- whatever is in stdlib and is "good enough" would work.

I also tried to make it a bit more flexible: to use `bcrypt` one can provide their own `pennybase.HashPasswd` function. To use SQLite one can implement five methods of `pennybase.DB` interface. It's not perfect, but at the code size of 700 lines it should be possible to customise any part of it without much cognitive difficulties.

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

#45

Post by zffr »

CharlesW wrote: post #29

Pocketbase is already the poor man's BaaS, and is minimalist compared to the two others mentioned. > Data stored in human-readable CSVs The choice to not use a database when two near-perfect tiny candidates exist, and furthermore to choose the notorious CSV format for storing data, is absolutely mystifying. One can use their Wasm builds if platform-specific binaries offend.

What’s the other candidate besides pocketbase?

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

#46

Post by jonny_eh »

zffr wrote: post #45
CharlesW wrote: post #29

Pocketbase is already the poor man's BaaS, and is minimalist compared to the two others mentioned. > Data stored in human-readable CSVs The choice to not use a database when two near-perfect tiny candidates exist, and furthermore to choose the notorious CSV format for storing data, is absolutely mystifying. One can use their Wasm builds if platform-specific binaries offend.

What’s the other candidate besides pocketbase?

Firebase, Supabase, Pocketbase

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

#49

Post by porridgeraisin »

nico wrote: post #37
TekMol wrote: 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…

> Do we still need a back-end, now that Chrome supports the File System Access API on both desktop and mobile? Could this allow accessing a local db as well? Would love something that could allow an app to talk directly to a db that lives locally in my devices, and that the db could sync across the devices - that way I still get my data in all of my devices, but it always stays only in my devices Of course this would…

> Btw, does Chrome sync local storage across devices when logged in?

No, but extensions have an API to a storage which syncs itself across logged-in devices. So potentially you can have a setup where you create a website and an extension and the extension reads the website's localStorage and copies it to `chrome.storage.sync`.

Sounds like an interesting idea actually.

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

#50

Post by loeber »

CharlesW wrote: post #29

Pocketbase is already the poor man's BaaS, and is minimalist compared to the two others mentioned. > Data stored in human-readable CSVs The choice to not use a database when two near-perfect tiny candidates exist, and furthermore to choose the notorious CSV format for storing data, is absolutely mystifying. One can use their Wasm builds if platform-specific binaries offend.

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