I agree. I would love to see more articles on pocketbase. It's phenomenal and ganigeorgiev is an animal about responding to bugs and discussions. He's got to be a hybrid human and ChatGPT robot.
Re:Migrating from Supabase
by ilrwbwrkhv on Friday May 19, 2023 @04:13PM
(#36006326)
What's also really cool is that you can also just use PocketBase as a Go library and just build your app around it like any normal web framework, while still having a great UI for quick prototyping. And when you need more custom behaviour instead of database functions, you just write some Go code while still compiling everything down to a single binary that you can copy over.
Re:Migrating from Supabase
by dingledork69 on Friday May 19, 2023 @04:32PM
(#36006536)
I don't use supabase, but am a big postgres fan:
> that stuff in unmaintainable
Wrong. Version your functions and use something like liquibase to apply migrations.
Re:Migrating from Supabase
by ilrwbwrkhv on Friday May 19, 2023 @04:35PM
(#36006573)
And handwrite xml? No thanks. Again, if I wanted to do any of this management myself, I wouldn't be using a PaaS.
Re:Migrating from Supabase
by dingledork69 on Friday May 19, 2023 @08:04PM
(#36008169)
You don't have to use the xml format if you don't want to. Not sure why you wouldn't want to, since the xsd enables autocompletion in your IDE which makes it the most practical format of all.
Anyway, YAML and SQL format are a thing
https://docs.liquibase.com/concepts/changelogs/yaml-format.h...
https://docs.liquibase.com/concepts/changelogs/sql-format.ht...
Or Bytebase if you want a more sophisticated GitLab like experience
Way less friendly than writing code IMO
Re:Migrating from Supabase
by dingledork69 on Friday May 19, 2023 @08:06PM
(#36008176)
Far, far more performant though for filtering millions of rows
Re:Migrating from Supabase
by flagrant_taco on Saturday May 20, 2023 @12:44AM
(#36009439)
Developer friendly matters early on, performance and security friendly matters at scale
Re:Migrating from Supabase
by datavirtue on Friday May 19, 2023 @05:38PM
(#36007146)
"Local development is a massive pain"...that's enough to kill it for me. No need to point out anything else.
Re:Migrating from Supabase
by jgraettinger1 on Friday May 19, 2023 @06:27PM
(#36007487)
> Row level security is their "foundational piece", but there is a reason why we moved away from database functions and application logic in database over a decade ago: that stuff in unmaintainable.
Funny. In my experience, application-level authorization checks are very error-prone, easy to accidentally omit, and difficult to audit for correctness."Unmaintainable", I suppose.
Whereas RLS gives you an understandable authorization policy with a baseline assurance that you're not accidentally leaking records you shouldn't be.
RLS is great, but it's not that hard to shoot yourself in the foot or miss stuff. E.g.:
ALTER TABLE bookmarks ENABLE ROW LEVEL SECURITY;
CREATE POLICY bookmarks_owner ON bookmarks USING (owner_id = auth.uid());
CREATE VIEW recent_bookmarks AS SELECT * FROM bookmarks ORDER BY created_at DESC LIMIT 5;
Re:Migrating from Supabase
by steve-chavez on Friday May 19, 2023 @09:07PM
(#36008489)
For that there's security invoker now:
CREATE VIEW recent_bookmarks WITH (security_invoker=true) AS
SELECT * FROM bookmarks ORDER BY created_at DESC LIMIT 5;
Indeed - one of the great changes in v15. (for any folks on previous versions, you need to change the view owner to a non-superuser role without the bypassrls attribute).
Thanks for all your work on PostgREST, Steve! Do you think we'll see relational inserts in the near future, or is that still a bit down the road?
Re:Migrating from Supabase
by another_story on Friday May 19, 2023 @06:50PM
(#36007703)
Could you be more specific what is difficult about local development? I've used it locally and had little difficulty.
Even though it looks like a great product initially, it has a lot or errors and bugs when you are trying to actually build something more robust than a toy app.
Local development is a massive pain with random bugs.
The response time of the database also varies all over the place.
But the most important problem that we faced, was having so much of application logic in the database.
Row level security is their "foundational piece", but there is a reason why we moved away from database functions and application logic in database over a decade ago: that stuff in unmaintainable.
There is also really poor support and at the end of the day, the whole platform felt like a hack.
I think now, for most apps with up to 500_000 users (with 10_000 concurrent realtime connections) PocketBase is the best PaaS out there having tested a bunch of them.
A single deployable binary which PocketBase provides is a breath of fresh air.
Anything more than that, just directly being on top of bare metal or AWS / GCP is much better.