Firebase gives me a list of use cases https://firebase.google.com/use-cases and documentation whose left nav gives me a good insight into the high-level functionality it provides "authentication, storage, hosting, security rules, extensions, machine learning, etc"
I think it's safe to assume you don't provide all of those, but i don't know what subset you DO provide. As a result, if i give you the benefit of the doubt, telling me it's a "replacement for firebase" is not meaningful because i don't know what parts it can replace unless it's just the few listed in which case it's absolutely _not_ a replacement.
"Lightweight replacement" also implies missing features, IMO. This project has - at the minimum - authentication, storage and hosting in a single binary that can be self-hosted. This absolutely can replace Firebase for some use-cases (e.g. on my LAN/homelab)
Aside: your tone is weirdly - and needlessly combative. If you see no value in this project to yourself, that is fine, but it appears to be making you angry for some unfathomable reason.
You can also think of them as software like postgrest but with the addition of authentication and other app oriented features, and with a JavaScript client library out if the box.
This program is doing the same thing in a more lightweight way as a single executable using sqlite.
The idea is that by using this type of generic backend software for your database and authentication, you can basically just write the remainder of a typical app or webapp entirely as client side/frontend software, which is something that you can also do with firebase, but this allows you to easily self host it without having to create your own custom backend software.
I guess you could describe it as "CRUD boilerplate" although that could also make it sound like the main purpose is to provide database table/form views like Microsoft Access which isn't really accurate.
It provides a database rest API like PostgREST with authentication so that you can write whatever frontend you want for it.
Since you say that you're familiar with firebase, imagine you're writing an android app using react native or something that uses firebase as the backend to store users' posts (or whatever they are).
The idea is that if you want to self host it instead of using firebase, you just run this type of software on your server and it will provide the basic functions that any client side app would need on the backend: storage for users' data as well as handling accounts.
I don't think it's really that complicated; it's basically just an interlace to a database, but if you look at something like PostgREST that automatically creates a rest api for a database, you would probably think "wow, I could almost create an app just using this as the backend without having to create my own backend, but I would have to handle authentication/registration myself," so these types of platforms just go a little further and handle that as well.
> PocketBase could be used as a standalone app or as a Go framework/toolkit that enables you to build your own custom app specific business logic and still have a single portable executable at the end.
> a Go framework/toolkit that enables you to build your own custom app specific business logic
that definition applies to literally every framework and toolkit. It tells me nothing.
You're quoting selectively in a way that elides meaningful parts of the sentence, and then stating that the description lacks meaning.
i have no idea what you mean by a "backend". If it's got a "admin dashboard" it's got a UI which means it's got a front-end which means it's not a backend. I'm assuming "go backend" isn't specific to go but just indicating that it's written in go.
it's got a example code block but doesn't explain the point of it. Why would an existing framework with a UI and everything need me to write a `main` method? Why doesn't it have one already? If it doesn't have one why doesn't it. If it does have one why am i not using it? My thinking here is that there are many existing patterns for registering plugins / extended functionality that don't require altering the main method of the thing you're hooking into. Why aren't you using that? Is this maybe intended to be like... a starter template for a Sinatra like thing with a pre-defined set of functionalty? Kind-of like how Django sets up model administration UIs for you?
re your summary here and the site:
i have no idea what "backed-in files" means and I've been doing web-dev for decades.
"convenient Admin dashboard UI" ... to admin / do what?
"simple REST-ish API" a) why "ish" and not actually REST b) ... that let's me do what?
--- in summary.... this looks useful but i don't get what you're actually offering or what it's intended usage scenario is. This is compounded by the fact that you're using a very atypical definition of one word "backend" and a very uncommon term "backed-in files"