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

131–135 of 135 posts

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

#131

Post by SOLAR_FIELDS »

tommica wrote: post #108
SOLAR_FIELDS wrote: post #87

Earlier quoted context omitted.

I just deployed a wasm built SQLite with FTS5 enabled and it’s insane what it is capable of. It’s basically elasticsearch entirely on the client. It’s not entirely as robust as ES but it’s like 80% of the way there, and I repeat, it runs on the client side on your phone or any other SQLite supported device

How large of a bundle is it? And are we talking about wikipedia stuffed into sqlite, or only a few hundred pages of internal docs?

I'm using wa-sqlite, and the standalone wasm package is 714kb. The use case is a few hundred pages of internal docs.

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

#132

Post by SOLAR_FIELDS »

bsaul wrote: post #115
SOLAR_FIELDS wrote: post #87

Earlier quoted context omitted.

I just deployed a wasm built SQLite with FTS5 enabled and it’s insane what it is capable of. It’s basically elasticsearch entirely on the client. It’s not entirely as robust as ES but it’s like 80% of the way there, and I repeat, it runs on the client side on your phone or any other SQLite supported device

how large is the wasm package for an empty sqlite, together with the client library to access it ?

the standalone wasm package is 714kb

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

#133

Post by ehutch79 »

sneak wrote: post #129
ehutch79 wrote: post #126

Earlier quoted context omitted.

What does that look like, and how does that prevent a compromise exposing users whose non-unique passwords are stored in a known broken hash?

if you enforce long random server-assigned api keys they are guaranteed to be unique. you don’t need bcrypt or pbkdf with api keys, as they are not passwords. they are high entropy and unique and long - unlike passwords.

Ok, but if the passwords are stored in a broken sha hash, and the server is compromised, how do api keys prevent users who use “packers123” for every site from having their passwords exposed?

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

#134

Post by bob1029 »

ehutch79 wrote: post #133
sneak wrote: post #129

Earlier quoted context omitted.

if you enforce long random server-assigned api keys they are guaranteed to be unique. you don’t need bcrypt or pbkdf with api keys, as they are not passwords. they are high entropy and unique and long - unlike passwords.

Ok, but if the passwords are stored in a broken sha hash, and the server is compromised, how do api keys prevent users who use “packers123” for every site from having their passwords exposed?

I think the more interesting conversation goes like:

How many CPU seconds should I burn for every user's login attempt to compensate for the remote possibility that someone steals the user database? Are we planning to have the database stolen?

Even if you spin for 30 minutes per attempt, someone with more hardware and determination than your enterprise could eventually crack every hash. How much money is it worth to play with a two-layer cake of unknowns?

Has anyone considered what the global carbon footprint is of bitcoin mining for passwords? How many tons of CO2 should be emitted for something that will probably never happen? This is like running the diesel generators 24/7/365 in anticipation of an outage because you couldn't be bothered to pay for a UPS.

Post reply on HN