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

111–120 of 135 posts

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

#111

Post by TekMol »

gavmor wrote: post #74
TekMol wrote: post #70

Earlier quoted context omitted.

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?

As far as I know, Dropbox does not merge data.

I never tried it, but from the descriptions I have read, Dropbox detects conflicting file saves (if you save on two devices while they are offline) and stores them as "conflicting copies". So the user can handle the conflict.

As a developer, you would do this in the application. "Hey, you are trying to save your data but the data on disk is newer than when you loaded it ... Here are the differences and your options how to merge.".

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

#112

Post by TekMol »

gausswho wrote: post #99
TekMol wrote: post #71

Earlier quoted context omitted.

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.

I may have misunderstoood. Does that mean with this API on both desktop and phone I can point to an arbitrary drive on the system without restriction? If so, it does indeed do what I'd like.

That's basically how the File System Access API works, yes.

Technically probably not completely "without restriction". But for all practical purposes, it works just fine for me.

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

#113

Post by gavmor »

TekMol wrote: post #111
gavmor wrote: post #74

Earlier quoted context omitted.

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

As far as I know, Dropbox does not merge data. I never tried it, but from the descriptions I have read, Dropbox detects conflicting file saves (if you save on two devices while they are offline) and stores them as "conflicting copies". So the user can handle the conflict. As a developer, you would do this in the application. "Hey, you are trying to save your data but the data on disk is newer than when you loaded it…

> Hey, you are trying to save your data but the data on disk is newer than when you loaded it

You're suggesting an actual API-facilitated data sync via Dropbox? Sure, but at that point why? Unless the data also needs to be read by 3rd party applications, might as well host it myself.

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

#114

Post by TekMol »

gavmor wrote: post #113
TekMol wrote: post #111

Earlier quoted context omitted.

As far as I know, Dropbox does not merge data. I never tried it, but from the descriptions I have read, Dropbox detects conflicting file saves (if you save on two devices while they are offline) and stores them as "conflicting copies". So the user can handle the conflict. As a developer, you would do this in the application. "Hey, you are trying to save your data but the data on disk is newer than when you loaded it…

> Hey, you are trying to save your data but the data on disk is newer than when you loaded it You're suggesting an actual API-facilitated data sync via Dropbox? Sure, but at that point why? Unless the data also needs to be read by 3rd party applications, might as well host it myself.

Sure. You brought up Dropbox. Not me.

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

#115

Post by bsaul »

SOLAR_FIELDS wrote: post #87
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.

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 ?

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

#116

Post by fer »

deepsun wrote: post #82
vineyardmike wrote: post #67

Earlier quoted context omitted.

Can't argue with what works, but... All these benefits also apply to SQLite, but SQLite is also typed, indexed, and works with tons of tools and libraries. It can even be stored as a static file on various serving options mentioned above. Even better, it can be served on a per-page basis, so you can download just the index to the client, who can query for specific chunks of the database, further reducing the bandwidt…

Just to be pedantic, SQLite is not really typed. I'd call them type-hints, like in Python. Their (bad IMHO) arguments for it: https://www.sqlite.org/flextypegood.html

> Just to be pedantic, SQLite is not really typed. I'd call them type-hints, like in Python

Someone already chimed in for SQLite, so worth mentioning that Python is hard typed, just dynamic. Everyone has seen TypeError; you'll get that even without hints. It becomes particularly obvious when using Cython, the dynamic part is gone and you have to type your stuff manually. Type hints are indeed hints, but for your IDE, or mypy, or you (for clarity).

It's a bit like saying C++ isn't typed because you can use "auto".

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

#117

Post by fmbb »

CharlesW wrote: post #59
zffr wrote: post #45

Earlier quoted context omitted.

What’s the other candidate besides pocketbase?

Apologies to anyone who found this unclear — the two near-perfect tiny candidate databases are SQLite and DuckDB.

The data files are not human readable though, right?

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

#118

Post by jpc0 »

ncruces wrote: post #72
CharlesW wrote: post #60

Earlier quoted context omitted.

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)

> SQLite will be there in 2035, but maybe not the current Go drivers

Go binaries are statically linked, unless you expect the elf/pe format to not exist in 2035 your binary will still run just the same.

And if not well there will be an SQLite driver in 2035 and other than 5 lines of init code I don’t interact with the SQLite drover but rather the SQL abstraction in golang.

And if it’s such an issue then directly target the sqlite C api which will also still be there in 2035.

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

#119

Post by jpc0 »

jasonthorsness wrote: post #27
christina97 wrote: post #26

Earlier quoted context omitted.

Go doesn’t have sqlite in the stdlib?

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

Define cross platform here?

I’ve heard this complaint but have yet to have an issue deploying to Linux/MacOS/Windows on arm or x86 using CGO backed libraries.

Maybe if you truly are targeting some niche platform but then you likely have some other issues to contend with and where are you deploying to?

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

#120

Post by ncruces »

Imustaskforhelp wrote: post #110
ncruces wrote: post #43

Earlier quoted context omitted.

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

Yes btw if I may ask, how does the modernc code actually work and like, if I wanted my code to be minimalist, what should I rather pick? Also didn't expect that I would be talking to the author of wazero myself haha. I really admire your project.

I'm not the author of wazero, although I've been a maintainer. I'm just the author of the wazero based SQLite driver.

modernc takes the SQLite amalgamation, runs it through the C preprocessor, then converts the result to Go file using the ccgo compiler. Not many further details on how that works: https://www.reddit.com/r/golang/comments/1apreer/comment/kqa...

The Wasm version takes the same SQLite amalgamation and compiles it to portable Wasm using clang/wasi-sdk; the platform specific bits are implemented in Go.

I'm not sure I can say which one is more minimalist with a straight face. One consists of mechanically generated, platform specific, 8MB Go files. The other embeds 1.5MB Wasm BLOB and needs wazero (a big dependency on its own).

Post reply on HN