Migration from Lucia

[Rykuno]

Lucia is being deprecated apparently. lucia-auth/lucia#1707

Luckily with the abstractions already in place this is an easy task. I'll have to refactor anonymous sessions and some future features i was going to push this morning but it shouldn't take much time.

[BradNut]

@Rykuno, yeah that was sad news but at least the guide is easy to follow and understand. It will be great to see this implmenented in TofuStack along with the anonymous sessions. Looking forward to it!

[pk992]

I've used better-auth to replace Lucia, frequent updates and a lot of features included.

[wysher]

Hi, @Rykuno I wanted to add new SessionService in replacement of to-be-deprecated lucia, but found this issue. If you haven't started this yet, I'd be happy to do so.

[Rykuno]

@pk992 Boring is better. Auth is not hard and i was hesitant to even implement Lucia(oh the irony). The v2 of this stack is completely hand rolled and improves upon the lucia implementation significantly.

@wysher I have a few more hours of work today and ill push up my v2 of this repo I've been working on. Its currently in a private repository but if you want to try it out lmk and i'll add you and whoever wants to give feedback.

Sorry its taking so long, works has been kinda crazy lately and ontop of that - I've been building my next application off the v2 of this boilerplate and wanted to make more headway before releasing it. Building actual apps off a boilerplate leads to so many necessary changes and actual real world improvements.

Edit: Might take a day or two longer for v2 - I have early previews of some svelte packages I have to remove or wait until their public release. Its not much effort but I won't have the hours till this weekend - sorry.

[wysher]

@Rykuno I'll be happy to test it out and give some feedback :)

[jsjg-8]

Hello, @Rykuno, Will the next version be drastically different? Or I will be able to migrate easily? Currently trying to build with your last update, I think I will stick to the Front-end till you respond

[Rykuno]

So this project isn't really "boilerplate" and I don't mean to market it as such. This is just me sharing to the community the way I build apps. Naturally as I gain more experience, the way evolves. This upcoming v2 is the culmination of experience I've had in the past year building in svelte/node. That being said...

Things that stayed the same,

1. The core philosophy of having the best local DX possible with 0 external signups necessary.
2. Always free.

The primary changes,

1. Turborepo. The api is no longer bootstrapped onto sveltekit. This helps me build more complex multitenant apps and pair with mobile easier. Ontop of that dealing with workers/queues/jobs are a kinda pain on a sveltekit backend.

2. No more Lucia and auth is now in Redis. I fully reply on a very simplistic and secure self rolled auth using email 2fa. Sessions are also a bit more feature rich and stored in redis now. Since lookup is done upon every request, the more request intensive apps were just making double the calls to postgres. I'm a cheap boi and like to run small VPS setups so I optimize where I can. It also has the added benefit of multi-tenant apps just requiring a quick and simple redis check to see if a user is authed.

3. TanstackQuery & removal of server files. I've stopped using +page.server.ts and .layout.server.ts almost entirely. It really makes little sense to when you have a separate api anyhow and only adds unnecessary boilerplate and prop drilling.

   This is for a few reasons,

   • Sveltekit does not have a way to partially invalidate a load function. This PR describes my issue. So if I want to invalidate some data, I invalidate all component AND parent data. Not ideal for data/processing intensive apps which I'm currently building and will be in future apps.
   • Proxying form submissions to server actions only to proxy AGAIN to an api is kinda annoying and useless.
   • Tanstack and query keys just makes building dynamic apps easier. The tanstack svelte 5 build is leaps and bounds better than 4 and finally what i consider stable.
   • Capacitor/Tauri capable. server files don't work with these. My next couple apps will have a mobile companion/compliment so I want them to be ready out of the box.

4. No more TSyringe. I'm really tired of the overcomplexity of IoC/DI and people just not allowing these libs to be maintained. Typescript 5 supports decorators out of the box now. No more needing to modify tsconfig and requiring reflect-metadata everywhere. Needle-DI is the best IoC/DI library I've used in node. Its source code is so incredibly clean and simple that I could just maintain it if it ever gets abandoned; but ATM its future proof for the next decade as it is and leaps ahead of others.

5. API is simpler. Way more simple.

6. I've moved hosting to railway.app. I love render.com and will continue to use them for my larger projects. BUT being able to spin up this ENTIRE stack(email,storage,backend,frontend,chatbots) on a $5 m/o server is insane from a pricepoint. I've already created the template for 1 click deploy.

7. I'm working on documentation for you guys. I get too many messages and when I'm infront of my computer I wanna code or play Ashes of Creation if their servers stop lagging. I get found on reddit and even get emailed somehow with questions. Hope these docs help.

8. Mailpit. Mailpit is so cool and I love it for local development/testing. I even have a VSCode extension in the works.

9. Since this is a monorepo I'll ship some examples with NextJS/React/Vue as well. Svelte is king, but I hope others from those communities can learn from my experiences too.

I've been saying I'll ship this for a while now, but svelte 5 and all its packages being updated made me wait. I also am in the middle of building an app with this exact new stack before I recommend it to anyone. Pretty dumb if I say "hey look at this stack, I haven't made any production apps with it but I BET YOU CAN MAYBE". Before I share this with anyone I want to make sure it has been proven and iterated upon. Going to party in Japan for a while but I'll be done in like a month maybe with v2 and its complimenting prod app.

If you're not building realtime, network heavy, more complex apps then this current codebase works just fine. I recommend that you fork this code and change it to suit your needs atm.

[jsjg-8]

Okay then, thanks for your extensive answer.