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

11–20 of 135 posts

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

#11

Post by reactordev »

jitl wrote: post #8
reactordev wrote: post #7

Earlier quoted context omitted.

Indeed bcrypt is preferred but this is just a simple backend. My first ick was using CSV as storage as opposed to golang’s builtin SQLite support. A SQLite connection can be made with just a sqlite://data.db connection string.

Golang does not have built in SQLite. It has a SQL database abstraction in the stdlib but you must supply a sqlite driver, for example one of these: https://github.com/cvilsmeier/go-sqlite-bench However using the stdlib abstraction adds a lot of performance overhead; although it’ll still be competitive with CSV files.

Ok, one additional dependency to your go.mod - big deal. And by builtin I was referring to the database/sql module which was designed for this.

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

#12

Post by thomascountz »

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…

TIL! I enjoy building cloudless apps and have been relying on localstorage for persistence with an "export" button. This is exactly what I've been looking for.

A lot of what I've read about local-first apps included solving for data syncing for collaborative features. I had no idea it could be this simple if all you need is local persistence.

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

#13

Post by jitl »

miroljub wrote: 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?

Minimalism. It’s tiny and its data can be completely administered with `vim` and `sha256sum`

Given the setup I’d guess it makes sense for little household scale apps w/ a user list in the low tens of people.

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

#14

Post by gavmor »

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…

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.

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

#19

Post by fkyoureadthedoc »

reactordev wrote: post #11
jitl wrote: post #8

Earlier quoted context omitted.

Golang does not have built in SQLite. It has a SQL database abstraction in the stdlib but you must supply a sqlite driver, for example one of these: https://github.com/cvilsmeier/go-sqlite-bench However using the stdlib abstraction adds a lot of performance overhead; although it’ll still be competitive with CSV files.

Ok, one additional dependency to your go.mod - big deal. And by builtin I was referring to the database/sql module which was designed for this.

maybe this is why they used sha-256 too, it's in the stdlib whereas bcrypt is a package (even if "official")
Post reply on HN