Getting SvelteKit closer to full-stack

[ermincelikovic]

Hello Svelte folks!

A little bit of introduction

I've been using Svelte since the 'Rethinking Reactivity' talk, shipping numerous SPAs. Recently, I transitioned to SvelteKit for a full-stack project. The first challenge was implementing authentication and establishing a database connection.

Traditionally in the PHP full-stack world, where I come from, this requires minimal configuration. But in the JS ecosystem, it involved creating and populating 10 files from library docs, with many edge cases still unaddressed. This cumbersome process was further complicated by the library's deprecation right after implementation (looking at you, supabase-auth-helpers).

I understand how we got here and I blame no single party.
However, I refuse to believe that we do not want to change anything about it.
As I align with most of the values of the Svelte team, I decided that this is the church I should pray at.

In opposition to the faster horse, let my first proposal be a car.

SvelteKit Routing in Libraries

Consider a npm library built for sveltekit that defines a routing tree, like this:

@supabase/sveltekit
  hooks.server.js
  /src
    /helpers
       auth.js
    /components
       LoginForm.svelte
       ForgotPasswordForm.svelte
       AccountSettings.svelte
    /routes
        +layout.js
        +layout.svelte
        +page.server.js
        /auth
            /login
                +page.svelte
            /register
                +page.svelte
            /forgot-password
                +page.svelte
            /errors
                +page.svelte
            /callback
                +page.js
            /pin-verify-callback
                +page.svelte
                +page.js
        /account-settings
            +page.svelte
        /delete-account
            +page.svelte

This structure could easily integrate into your project's routes. Perhaps using hooks, or as a vite plugin, or something else. It could even be pointed to different local route, like /app.

For customizations, users could override the library's default templates or functions by creating files with the same names in their projects and accessing library props for modifications. This method could even support chaining libraries, enhancing efficiency and creativity.

If you're skeptical about plugin systems due to potential messiness, I understand. Still, I believe we can refine this ecosystem for more efficient and enjoyable functionality reuse.

Outro

I would be more than happy to demonstrate to the svelte core team how WordPress built its plugin mechanisms and why millions of users and developers can use and build in the ecosystem where plugins interact with each other beautifully.

More importantly, I would love to show how a couple of examples of what community built thanks to the platform possibilities, as I believe we can do it even better.

Best,
Ermin

[jycouet]

I think that there is a need as well, but I'm not sure how to structure all this.

---

On your initial idea / proposal, some questions 👇

1/ hooks.server.js

I guess that this will hold all endpoints, and lib users will need to give a few options. Something like:

handleSupabase({ authPath: '/auth', protect: '/app' })

In addition, this handle can be a sequence, and we need to be able to give orders for each handle and merge with app sequence. It can get messy, but to me, it seems manageable if we are open.

The question is: where should we set all this? svelte.config.js kit plugins?

2/ +page.svelte && +layout.svelte

Quite simple to understand, if you don't have it in your app, use the one coming from the lib.
What about dependencies used? (stores, libs, components...) It should all come with the package. (It's maybe just a way to "package" it?)

If I want to overwrite it, how to access stores that was used in the default one? We should be able to import from the package?

3/ /routes

In the example, all stuff at the root of routes will be rarely "available". I mean, users will probably have their own stuff there, so they will have to copy what lib author had in mind there?

What if 2 libs provide /routes/+layout.svelte? Should, as a user, be able to select? (where do you do this setting?)

---

I would like to open my mind, if anyone has ideas, I'll be happy to read 👍

[jycouet]

Just trowing this here : is shadow routing (kit 2) helping here? 👀

[SergeantWeb]

@jycouet brought me here :D
Perhaps my plugin system could be suitable for that purpose: https://github.com/SergeantWeb/sveltekit-plugin-system

However, I didn't create it with the idea of maintaining the same file structure, which could be a nice improvement, I'll try to do something that's more suitable for building a routing library.

[PatrickG]

Just linking this here #6708
Seems related

[coryvirok]

Thanks @ermincelikovic for writing this up. You've described some of the pain points I've also felt, but did so in a nicely succinct way.

I really only have experience building plugins in Flask, Rails, Pyramid but my advice for Kit is to stay away from trying to integrate with Kit on the server. I'd recommend building a non-Kit aware plugin that is provided with a request object and returns a POJO that includes the response body/partial, headers, etc and then provide that as a module that Kit users can import in their actions/endpoints/tests. There is a bunch of black magic that happens in Kit for the server-side that make it very challenging to create plugins the way you're describing.

Rant:

I also come from the "backend" world of server rendered dumb apps served up by the likes of Django/Flask/Rails/etc and I share some of the pain you describe here. After hacking with/on Kit for a year+ now and getting somewhat used to how things are designed/work I'm pretty sure the current cohort of web frameworks (Kit, Next, Solid, etc.) will continue to move away from the top-down web app approach that Rails/Django/etc all implement.

This cohort has designed themselves bottoms-up, meaning they started with the client making all control flow decisions and bolted on server-side functionality. This is pretty nice for frontend devs, but it makes the server-side extremely challenging. Mostly because there is no simple request -> router -> middleware -> route -> render -> respond flow. E.g. take a look at how Kit does parallel rendering for layouts and pages. A side effect of this design is that it's super confusing how to do things like auth or DB transactions without writing some fairly heinous code in hooks.server.js.

That said, once you understand things and accept the challenges, you'll be able to build some really compelling apps that feel like SPAs but still allow you to do SSR and other web 1.0 things.