Hm, there is nothing preventing you to start multiple services from a single binary.
I'm not sure that PocketBase would be suitable for your use case, but it is distributed also as a Go package (see https://pocketbase.io/docs/use-as-framework/) and you could combine it with any other GUI Go package (fyne, go-astilectron, etc.)
By default PocketBase uses the local filesystem, but you could also configure a S3 compatible storage (AWS, DigitalOcean, Vultr, etc.) from "Settings > Files Storage > Use S3 storage".
I've started working on the project ~ 3-4 months ago. The last 4 weeks I've taken a longer break from my day-to-day job so that I could finalize the first release.
It's implemented in the application, it's not a feature of SQLite, but its very simple and robust - when a record is created/updated/deleted I'm broadcasting the change to all subscribers that are allowed to receive it (the access control is based on the colleciton's list and view rules).
Reading through the code/docs it looks like you can subscribe to individual records (database rows) or collections (tables), is this correct? In your Records.getList method, you have filter functionality that would be nice to subscribe to (ie. subscribe to changes in "demo" collection where totalComments > 10). Subscribing to a specific result set seems like it could scale better than notifying subscribers of all table changes, which then get filtered in the subscribe() callback func in the SDK. Very cool work!
Yes, you can subscribe to individual records or collections.
User defined filters for the subscriptions are not supported, but it's a good idea and I may consider it in the future.
Currently the subscriptions are filtered through the collection's list and view rules - they also act as "admin level filters", aka. filters that are always applied and regular users cannot modify (getList user defined filters are only appended to the search query together with the admin defined filters).
That makes a lot of sense. Thanks for the link. I've not worked with Go before so I couldn't find exactly where the implementation was.
This looks like a very interesting project and great for some of the small client projects which I currently use Firebase. I'll be sure to take a proper look in the future!
Other than some json functions, PocketBase doesn't use too much SQLite specific features, but I don't plan adding support for other databases at the moment.
Please also note that PocketBase is designed to be deployed only on a single server, so it cannot scale horizontally out of the box. Supabase/Nhost are better suited for that.
Yes, I'm aware of this limitation, but PocketBase uses HTTP2 when combined with the --https flag (this is by go's default net/http implementation) so it shouldn't be too much of a concern.
Go's default `net/http` package will serve HTTP2 when a https configuration is provided (also most web browsers don't support h2c, aka. HTTP2 without tls).
The default limit of ~100 connections should be more than enough for most applications (additionally, the JS SDK client maintains a single SSE connection for a page no matter to how many things the user has subscribed, so that also helps).
HTTP/1.1 has a limit, set by each individual browser vendor, for the maximum number of connections between a client and a unique server domain. So, if you exceed 6 simultaneous connections to that server (across multiple tabs and windows), it will move the request to a stalled state (like a queue) until one request is completed.
Best solution today is to move to http2 on your server -- which has an SSL (TLS 1.2) requirement.
Looks like pocketbase implements this. If you use another server, like nginx, you have to enable this for each site.
Did you intend to say baked-in? Like it's built-in? If so, I feel it's better to just use "built-in" because it's more familiar. The same typo's in the site too and confused me a bit.
You could read more at https://github.com/presentator/presentator/issues/183, but to summarize - I wanted something that could be self hosted with almost no additional setup and no dependency on 3rd party services.
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"
It's a lightweight replacement for Firebase. I
That's why it is described as a backend, because it's primary feature is to act as a data store. If don't understand what a project does, and you're unfamiliar with the comparisons given (Firebase, Supabase), the right thing to do would bw to look up the comparisons.
I know you have user management, a database, and do something with files. As noted before the "backed-in files" isn't a commonly used phrase so i'm left with 2 pieces of meaningful info, neither of which is particularly notable because every multi-user app has both of those.
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.
I'm not OP; I wasn't aware of the project until I read the HN headline.
"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.
I’m familiar with firebase and an electron developer and I still don’t understand what this project does. I wish I did, because it seems it’d be interesting to me. Even the app that uses this (Presentator) is described in a way that leaves me grasping for “bit what does it DO?”
There is a bunch of software in this space like supabase, flat backend, and appwrite that attempts to be a generic self hosted backend for apps in a manner similar to firebase by providing data storage and authentication with a rest API in an integrated fashion, usually with a built in admin interface for schema design, user management, etc.
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.
> Ok, so it's a self-hosted CRUD boilerplate with auth written in Go? Or a self-hosted Notion but with less view/UI customization out of the box?
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.
It can be used as a CRUD boilerplate for Go projects (where you extend it), alternatively you may use it as a standalone REST(-ish) API backend that integrates auth and storing & retrieving state from some other app in any language. It's similar to DjangoREST which can bw used in both modes (as a base for a project written in the same language, or purely as data layer interfaced via REST)
> 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.
It provides an authenticated rest API (with a premade JavaScript client library) to an sqlite database, so you can store users' data similarly to how you might use firebase.
Does it render pages automatically based on Schema? I see your really simple example under examples, and its so minimal I want to think you just get all the tables and render views from that. Am I crazy? If so this is really neat.
Did you ever consider using something like GORM? Because I could see this working with other databases and being extremely useful. I use Django to build really quick CRUD interfaces, but sometimes I need to be able to customize it more, and the admin UI is not as extensible as I would normally want, they even suggest you just build custom pages if its not doing what you need, which is a bummer because Django Admin covers the majority of my use cases.
I actually started with GORM, but its too complex and I ended up replacing it with a simpler query builder package (ozzo-dbx). While the query builder has abstraction for other databases, I'm not planning supporting them at the moment.
No worries, I've seen another project called UAdmin that kind of reminds me of this, my problem with UAdmin was that there were bugs and I didn't quite get why it worked how it worked, but having used Django since I realized what I was missing out on.
Thank you for following up, I did see you had a package for extending the built-in Go package for SQL.
