Choosing a Tech Stack: Sveltekit + Pocketbase vs. Go/HTMX + GoAPI(SSR) – Opinions Needed!

[axzilla]

I'm currently building a small app using Sveltekit and Pocketbase. I find Pocketbase simply fantastic!

While I genuinely appreciate Sveltekit, I struggle to warm up to TypeScript – it feels like there are too many possibilities for my taste. Hence, I'm considering building my frontend with Go and HTMX and adding a Go-API layer, functioning similarly to the Formactions and Load functions in Sveltekit.

Golang feels stricter to me in terms of typing and allows me to think more clearly. Additionally, I'm keen on diving deeper into Go.

I'm aware that Pocketbase is a BaaS system, and by pursuing this thought, I might be diverging from its core idea. I also understand that I'd have to directly call the API endpoints since Pocketbase doesn't offer a Go SDK.

Ultimately, my goal is to develop multiple MVPs as swiftly (yet securely and scalably) as possible to validate my MicroSaaS ideas in a short timeframe.

In short: Sveltekit + Pocketbase or Go/HTMX + GoAPI(SSR) + Pocketbase – what are your thoughts? Pros and cons?

Thank you!

[ganigeorgiev]

You usually don't need a Go client-side SDK to use PocketBase with your existing Go stack. PocketBase is distributed as a regular Go package and can be used as framework/toolkit, aka. it can live as part of your existing Go program and you can interact directly with the database without making extra http requests. It also exposes the underlying router (echo; it may change in the future) so users can use whatever rendering and template engine they prefer for handling the SSR routes.

My personal preference for web apps is usually embedded static client side application (eg. SPA) + generic web API because most of the time my use cases require targeting more than one platform and it is just easier for me to maintain them. But if you are targeting primarily the browser and don't need too much js interactivity, then I think Go SSR is a good choice (in addition to the Go std template lib there are plenty of other external Go template libraries to make the integration with htmx easier like templ, pongo, liquid, etc.).

---

While I genuinely appreciate Sveltekit, I struggle to warm up to TypeScript ...

You don't have to use TypeScript with SvelteKit, you can use plain JS. You don't even have to use SvelteKit to use Svelte. For SPA a simple hash based router like svelte-spa-router is usually enough to get the job done.

[axzilla]

Thank you for your insights.

To clarify my understanding: Given the uncertainty of potentially adding Flutter apps or other platforms in the future, it seems wise to completely decouple the frontend and backend. In my case, I'd have a Svelte(kit) web client and a separate Go backend interfacing with the Pocketbase BaaS.

While this may introduce a bit more overhead initially (as I'm aiming to quickly develop an MVP), it sets the foundation for scalability in the long run.

So, what I might save in the beginning in terms of development speed, I'll potentially compensate for in future scalability and flexibility.

Have I understood your recommendation correctly?

[ganigeorgiev]

Yes I think this is correct, but the above is just my personal preference so take it with a grain of salt.

[axzilla]

Got it, thanks a lot!

[axzilla]

Furthermore, when it comes to authentication, I’m a bit at a loss. Do you have any recommendations or example repositories on how to best handle it both on the client side with Sveltekit and on the Go API side, particularly in relation to authentication middleware?

[ganigeorgiev]

The question is a little vague and I'm not sure how to answer it.

Authentication in PocketBase out of the box is fully stateless and it expects that every logged-in user request has Authorization: TOKEN header with it.
The documentation needs a little more work, but in general if you use PocketBase as framework, then you can check "Retrieving the current auth state". There are also builtin middlewares that comes with predefined auth checks that you can use as part of your routes.

If your SvelteKit application is entirely client-side (aka. runs in the browser), then usually you don't have to do anything in addition as the JS SDK default AuthStore uses LocalStorage and will take care to "persist" it between requests and page refresh.

If you use SvelteKit SSR then you can check https://github.com/pocketbase/js-sdk#ssr-integration, but if you are not working on a website and/or you are not sure that you need it, then I'd advice to avoid JavaScript SSR/RSC as it comes with a lot of complications when having to integrate with 3rd party auth services (and this usually is true not just for PocketBase).

I'll try in the following weeks to add a guide with some client-side integration recommendations, but from my experience and the several open questions in the PocketBase repos, JavaScript SSR first approach seems to work well usually when you use PocketBase as pure data store, aka. when you interact with PocketBase APIs as admin (eg. pb.admins.authWithPassword(...)).

But when you bring the regular user auth state in the picture, this is usually when things start to get complicated because now you have to manage and sync the client-auth state between 3 layers: browser-node-PocketBase.

In this case you not only have to host and maintain two different server applications (node and PocketBase), but you are also limiting the PocketBase performance by the node server throughput because if every request is proxied through the node server (aka. browser->node->PocketBase) the request handling will depend on the single threaded node event loop (you can use clusters/workers or dedicated node process manager like pm2 to load balance the traffic but that complicates even further the setup). Network latency problems are also common when the 2 backend applications are not within the same network/region.

So to summarize, my general recommendation is:

1. Have an entire static client-side application (eg. SPA)

2. If you need to write custom server-side code (eg. to handle payments):

   • Use PocketBase as framework
   • OR if you don't like the above and/or don't want to rely on it because it is not stable, then you can have special one-off node/deno/bun/etc. server-side actions that will interact with PocketBase web APIs as admin

[axzilla]

First and foremost, thank you for the detailed information you've provided thus far. I admit that some of the technical intricacies are still somewhat unclear to me, but I'm striving to grasp them and implement them correctly in my project.

Client-Server Communication: From what I understand, you generally recommend having a dedicated API server (in my case, a Go backend) to communicate with PocketBase, rather than doing this directly through the client app (in my case, Svelte). This suggests I should be directing my CRUD requests from Svelte straight to my Go API, which in turn interacts with PocketBase. Is this correct?

Stateless Authentication: The concept of "stateless" authentication appears to pertain to a self-signed token, and if I'm not mistaken, this would be a JWT Bearer Token. Am I on the right track?

Token Validation: I'm a bit unsure about where the token validation takes place. Does the PocketBase JS SDK check the cookie on the client-side and ensure that the token is valid and not expired? Or is it the responsibility of the PocketBase app to inspect the "Authorization" header?

API Protection on the Go Server: While I understand how to protect the client-side routes of my Svelte app, I'm still uncertain about safeguarding the endpoints on my Go server, especially when these requests come from the Svelte app. Specifically, for the client-side route protection, I'm considering something like this:

if (!locals.pb.authStore.isValid) {
    throw redirect(303, '/login');
}

Do you have any recommendations or best practices on how I should best implement this?

I hope my concerns are articulated clearly. Please excuse me if some of my questions seem redundant – I'm simply trying to ensure I've got a full grasp on everything.

Thank you for your patience and assistance.