Live data from Hacker News

Show HN: PocketBase – Open Source realtime backend in one file

github.com

71–80 of 113 posts

Re: Show HN: PocketBase – Open Source realtime backend in one file

#71
post #64

This looks awesome! I will definitely give it a try. Right now I use postgres in a docker compose but its definitely a bit heavier for single machine prototyping. One thing that I like about my setup though is that there's a clear migration path to horizontally scale. Do you have a recommended way to move past pocketbase should an app get to that point?

I guess there will be differences from use case to use case, but in general migrating from PocketBase to a more common horizontal supported stack is not different from rewriting your application.

Internally, each Collection creates a standard SQLite table that holds the collection records, so migrating the data structure shouldn't be too troublesome. The only thing that may prove difficult to migrate could be reimplementing the access rules and filters.

But in my opinion, when your application reaches that level of growth requiring multiple servers and services, your business use cases mostly likely will have changed several times already from your initial idea.

Re: Show HN: PocketBase – Open Source realtime backend in one file

#73

Earlier quoted context omitted.

The pex tool lets you build single file python executables which are well suited for server deployments.

oh wow thanks i didn't know about this. in that case it would be super simple for me to wrap up a FastAPI server with SQLite or even some in-memory database that runs elsewhere, deliver as a single file!

You could also just use Docker to wrap anything

Re: Show HN: PocketBase – Open Source realtime backend in one file

#74

Earlier quoted context omitted.

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). The realtime api implementation could be found at https://github.com/pocketbase/pocketbase/blob/master/apis/re...

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 tab…

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).

Re: Show HN: PocketBase – Open Source realtime backend in one file

#76
post #60

Earlier quoted context omitted.

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…

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?

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)

Re: Show HN: PocketBase – Open Source realtime backend in one file

#77
post #64

This looks awesome! I will definitely give it a try. Right now I use postgres in a docker compose but its definitely a bit heavier for single machine prototyping. One thing that I like about my setup though is that there's a clear migration path to horizontally scale. Do you have a recommended way to move past pocketbase should an app get to that point?

Perhaps sharding data by geographical location could be one path - e.g. deploy one server in the US and another in Europe, each with its own database.

The whole concept of edge computing - deploying app servers closer to your users for minimal network latency - seems to go hand in hand with using an embedded database like SQLite. (I haven't tried it in production yet, but looking forward to.)

Re: Show HN: PocketBase – Open Source realtime backend in one file

#78
post #34

Earlier quoted context omitted.

If a selling point is run from "one file", that's quite difficult to do in python. There are things like pyinstaller but you end up shipping the entire interpreter in the bundle.

The pex tool lets you build single file python executables which are well suited for server deployments.

How big is a python3 runtime when pex has packaged it up? And do you happen to know what the output binary is linked to?

Re: Show HN: PocketBase – Open Source realtime backend in one file

#79
post #70

Nice but my super anal quip is please don't call this thing "realtime". It doesn't make sense in this context. What is realtime about it? Are there timing guarantees or are timing constraints provided in API requests? Because that's what realtime systems are. Realtime does not mean "real fast". For example, a train track switching system might be getting run by a 1MHz CPU and still be real time. It's not about speed,…

It’s not a real-time operating system. In this case, real-time means it is built such that a client gets access to updated database values as soon as they change, as opposed to a non real-time database which doesn’t necessarily have a built-in mechanism for reliably on time updates.
Post reply on HN