What are the pros/cons of this over firebase?
Pocketbase: Open-source back end in one file
71–80 of 151 posts
Re: Pocketbase: Open-source back end in one file
#72Earlier quoted context omitted.
Been enjoying using PocketBase with Astro + htmx + Alpine
nice! I'm curious to know why would you need Alpine or Htmx if you have one of them in your app? I thought they are mutually exclusive.
we go into detail on this in the client side scripting chapter of our book:
Re: Pocketbase: Open-source back end in one file
#73Pocketbase is amazing! So far I had a great experience using it as a backend/database for the app I'm building where I'm using React with Vite for the frontend. I'm using it mainly for auth and for keeping track of paid and free accounts. Some things that I found rather useful: - It's super easy to host. I was initially thinking of using Appwrite or Supabase but found it a tricky to self-host them, especially Supabas…
I feel like super easy to host needs to be re-emphasized. We're talking about dropping a single binary into your server and you're off to the races. If only more things were so simple.
Is that the same concept that Deno uses?
Re: Pocketbase: Open-source back end in one file
#74Out of all the PaaS I tried including Supabase and Appwrite, Pocketbase is the best. Great performance, intuitive features, actually self hosted and a joy to deploy.
Re: Pocketbase: Open-source back end in one file
#75Been using Pocketbase for almost all of my projects lately. Its realtime database is especially nice to introduce multiplayer functionality with relative ease. It plus SvelteKit has been a dream to get up and running using the JS SDK.
I’m curious how you’re integrating it with Sveltekit? Are you using Sveltekit just as a static generator?
Re: Pocketbase: Open-source back end in one file
#76Earlier quoted context omitted.
I use PocketBase for mostly everything where I need a back end now. I came across a situation where I needed to write a custom SQL join (technically I could have just fetched all the data and done it in Node, I suppose). I was shocked at how easy it was to write the query even inserting URL parameters and selecting based on the authenticated user only. Fully recommend for basically everything. Great app. Not sure it…
Interesting! I haven't made anything serious yet with the PocketBase (mostly due to lack of time & not anything to do with PB). I'm curious to know what kind of projects did you build using PB and how was your development experience?
One of my production projects with around 20,000 customers and 400k arr runs on Pocketbase with zero issues. I cannot recommend it enough.
Re: Pocketbase: Open-source back end in one file
#77I am a bit confused, is it the backend's backend? E.g. something that is used by the HTTP server app, like a DBMS would be? Or is it actually the backend, e.g. the frontend (browser) talks to it directly?
You would use it instead of things like Supabase and Appwrite. It gives you a server, a db and easy authentication, authorization with real-time queries like firebase.
Re: Pocketbase: Open-source back end in one file
#78Very cool. Reminds me of the encore framework, also written in go: https://github.com/encoredev/encore Need to spend some more time looking into these go based frameworks, they seem great for quick prototyping
Nope encore is horrible to use in comparison. Pocketbase is levels above encore and similar projects.
Re: Pocketbase: Open-source back end in one file
#79Cool homepage but I don't even understand what this thing does.
It's like a smaller Supabase, which was an open source alternative of Firebase. So basically a database, authentication, file storage, and backend in one solution.
It's substantially better than Supabase and much easier to host and deploy.
Re: Pocketbase: Open-source back end in one file
#80Earlier quoted context omitted.
I feel like super easy to host needs to be re-emphasized. We're talking about dropping a single binary into your server and you're off to the races. If only more things were so simple.
Isn’t that how any Go project is put online?
The key distinction here seems to be that it uses an in-core database (SQLite), whereas a Go project may depend on an out-of-core database like Postgres, which would then also have to be deployed.
For many projects (especially hobby projects where downtime is tolerable), the former is probably quite sufficient.