undefined | Better HN

0 pointsdimmke3y ago0 comments

SvelteKit + Supabase.

It’s the opposite of what a lot of people recommend. It’s not battle tested. Both of these technologies are still maturing BUT:

I can write everything in JS/TS, I don’t have to get good at Ruby PHP or Python

Postgres is a great skill to learn.

Supabase is portable and can be self hosted, and its JS client is easy to use for DB manipulation and stuff like object storage.

For me, building a true full stack web app (not a todo list tutorial but something with real custom features) was going to be a learning process because I’ve been so heavily front end focused. So I decided to try to learn with the most modern tools available. It’s mostly worked out. I’ve had to ask for help on Discord a lot, especially with Supabase.

I have this idea for a blog post called “it’s just a CRUD app” that kind of challenges this idea that CRUD apps are brain dead simple. When you look at the myriad of options for building and deploying one. We’re talking like 50+ frameworks. Methodologies like dependency injection, micro service and monolith patterns. Yeah maybe it’s simple if you have been doing it for 15+ years and are comfortable with your stack but if you’re newer to the game, there’s a lot of complexity at play and the best choices for your situation are not obvious. Before moving to Supabase I was using NestJS because I was convinced I needed this framework with guard rails, but I hated it. So moving off that caused a lot of churn.

Edit: I also wanted to mention that the biggest split amongst all these recommendations IMO is how the backend and frontend interact with each other. Some of these frameworks will render frontend views for you. Then you're dealing with a very classic web app. Then you hear other people in this thread talking about HTTP handlers, and it's clear they're talking about the backend existing as a REST API, which IMO is a bad pattern to use for your own app. REST APIs should be used for exposing your service to third parties.

But there's a third way, that's becoming popular amongst the "bleeding edge" with things like Next.js and SvelteKit that have a "backend for frontend" where they have to run a node/deno based server anyways to do on demand SSR and hydrate. Having a separate backend, especially a separate backend that is just a REST API leads to a ton of redundant code and confusion.

So instead with ORMs like Prisma, people setting a persistent DB connection on this backend server and accessing/manipulating the DB directly with some kind of client. I think this approach came to prominence alongside the rise of GraphQL. That's basically the way Supabase works - they have a JS client and you interact with it in a similar way you would Prisma or TypeORM. They even have an article about how their client can be used in a similar enough way to GraphQL that it's not worth using GraphQL instead.

Instead of traditional controllers where you would stash a lot of business logic (including authorization), the idea is you leverage PostgreSQL's advanced features to help with that. I'm not a huge fan of this for multiple reasons. So you kind of have to make your own decisions on how much abstraction you're going to put on top of their client.

0 comments

2 comments · 1 top-level

imnnos3y ago· 1 in thread

So I’m fairly new to the world of full stack web development. I’ve been trying to make an MVP using SvelteKit and Firebase, but what I’m running into is that they both kind of try and avoid a separate backend in different ways that seem to sometimes conflict with each other.

For instance, Firebase is meant to connect on the client so you don’t need the backend database connection, but then you can’t use SvelteKit’s SSR. Does Supabase work similarly in this aspect? What do you do in this situation?

dimmkeOP3y ago

The DB connection to Supabase can be made where ever you want it to be. It’s just JavaScript.

In Node, a “module” is generally scoped to a file. So you make a db.ts file and export the instance you create and it functions basically as a singleton. One DB connection per user per session. SvelteKit let’s you choose where to put that. The first place you import it is when it instantiates.

Auth in SvelteKit is trickier than it should be, but there’s a really good technique that I recommend you follow: https://www.captaincodeman.com/re-creating-the-sveltekit-ses...

I believe he uses firebase in his example. But don’t just copy paste, try to understand what is actually happening and why he had to do this workaround. Once you understand how SSR actually works, things get a lot easier.

Stores are a way of storing state on the client side, but to do SSR Svelte has to use stores on its “backend”. The key thing to understand is that stores that are used for SSR are server wide and persistent so you can’t store user specific data in them. There’s a special spot for that kind of state called events.locals.

It’s probably the trickiest area of SvelteKit IMO. I hope they make it better.

j / k navigate · click thread line to collapse