SvelteKit with traditional backends

[dghubble]

We have traditional backend apps that use Svelte (not SvelteKit) working very well. Existing services (non-Javascript, Go, Rust, etc.) render pages, serve the bundle.js file, and use plenty of Svelte components (e.g. top-level App and a whole tree of components, pass props, etc.), along with a router like tinro.

Enter SvelteKit, which seems to be recommended. First, Vite wants to serve the html (the real server has additional logic that's needed) and generates a bunch of js chunks by default (disable that to get a single bundle.js to put into an index.html https://vitejs.dev/guide/backend-integration.html). Next, SvelteKit seems to focus a lot on SSR +server.js functions - but we're not planning to use JS server side at all and end up disabling anything SSR related (https://www.npmjs.com/package/@sveltejs/adapter-static). SvelteKit's file-based router with +layout.svelte's and +page.svelte files (look at the path to figure out which page) seems less flexible (we end up mostly designing our own components). I don't mean this to be critical, more just figuring out whether SvelteKit is the right fit for the traditional backend use case.

I feel like we're mostly fighting against Vite and SvelteKit in these experiments, turning off features. What am I missing?

Is SvelteKit actually aiming to be the best way to build all Svelte apps? Or is it aiming for a narrower set of use cases? It seems designed for Netlify style apps, where frontend/backend are in Javascript/Typescript, a platform abstracts away the backend, and the whole app is pretty much a SvelteKit app. For those using traditional backends, where Svelte is just a small piece of the larger whole, does SvelteKit have a value proposition over plain Svelte?

Context: We're mostly backend/systems engineers, who like Svelte, but confused by SveltKit.

[eltigerchino]

SvelteKit's file-based router with +layout.svelte's and +page.svelte files (look at the path to figure out which page) seems less flexible (we end up mostly designing our own components).

What do you mean by less flexible and designing your own components?

I'm also curious regarding this topic as I have unsuccessfully tried pairing Laravel and Django with Svelte in the past (mostly due to my lack of knowledge).

[dghubble]

With Svelte, you make a top-level App or Page component and build a tree of components with composition. Its conceptually simple. Routing can be handled by any number of routing libraries if you wish.

With SvelteKit, you start off arranging various +page.svelte files in a file heirarchy. +layout.svelte files in parent directories become parent components. When you want to add other components, navbars, footers, side panels, you then also need regular Svelte component composition. Component logic can be defined outside components in other special locations. And when you edit multiple page components, in your editor you're looking at a lot of files all named +page.svelte. Using SvelteKit's approach to routing (which seems to be a key piece of its claimed value) adds more concepts to know and more ways to do the same thing while having strict naming rules one must follow.

I'd be great if there was some clear messaging to say "hey, SvelteKit isn't meant for traditional backend use cases where something else does server side rendering, you find the router cumbersome, etc."

[benmccann]

SvelteKit is absolutely meant to work with any type of backend. However, SvelteKit is a file system router. You have to accept that to use it as of right now. You can't setup routes programmatically. I don't think this creates any restriction on what you can build, but you do need to accept this. I don't really think it adds more concepts to learn. Yes, you have to learn it, but you have to learn the API of any router that you choose.

SvelteKit is generally meant to be your entire frontend. I probably would try to avoid mixing and matching SvelteKit with another frontend setup. It doesn't need to be any of your backend though and you can easily ignore any docs about .server files in that case

[maku]

@dghubble I am using sveltekit as a SPA with my "own" backend. (you have to use @sveltejs/adapter-static and export const ssr = false; in +layout.ts). The benefit of using sveltekit is you get a really powerful routing and layouting solution out of the box (and much more)

[dghubble]

We're using adapter-static and ssr false too. And +layout.ts is just a single specific kind of Svelte composition we can do with just Svelte. I could see SvelteKit routing vs other routing libraries being a preference sure. What's the "more" you're getting that make it worthwhile to you?

[maku]

I do not think that you can easily do composition stuff in pure Svelte what you can do with sveltekit (https://kit.svelte.dev/docs/advanced-routing#advanced-layouts) But maybe you do not need this. Furthermore, of course I can pick an extra lib to do routing but I prefer an "official" one which is supported in the future and is rather powerful (data loading etc)

[dghubble]

Fair enough. Thanks for sharing what convinced you

[coryvirok]

FWIW, I've found that all of the latest frameworks like Kit are not meant to integrate with existing web apps that have their own routing and request handling. Kit, Next, Nuxt, Astro, Vite + vite-plugin-ssr all assume their framework will handle figuring out which (page) component to render and the building of props to render that component.

I'm also coming from a backend dev experience where we have an app framework like Express or Django or Rails and a template that the framework passes data into to render into HTML before responding with 2xx/4xx/5xx. I've built my own "use Svelte like a traditional server-side templating engine" integration with Vite but it was a mess. Now, the closest I've found to ideal is Vite + vite-plugin-ssr. But it has it's own challenges.

I think Kit/Next/etc. are good for new projects that you want to run on Vercel/Netlify/Lambda. This probably means there's another backend that runs in your own VPC that can connect to your private resources (DB, queues, etc.) But I've struggled to see how they can easily integrate with an existing web app.

[david-plugge]

I've built my own "use Svelte like a traditional server-side templating engine" integration with Vite but it was a mess.

I´m curious, why did you choose vite for that? I´ve build an application that creates pdf files from html and used svelte for templating, it was actually pretty easy! I used rollup because vite doesn´t play nice that with a custom server.

[coryvirok]

Good question. Honestly i thought it was my only choice. And the vite-plugin-svelte looks like the only tool maintained by the svelte team. Also, I love the hmr dx of vite.

Now I'm curious. How are you using rollup directly?

[emmagamma]

If you configure your app to use the deno adapter, you could use deno's FFI (foreign function interface) to implement code in Rust or whatever other language, and call it from within a sveltekit server file.

There's also NAPI-RS for Rust and Node.js so it's more limited but it has auto typescript generation based on your rust types which is kinda nice.

[elikoga]

If you proxy the requests properly, then you can use a traditional backend in the same host using a judicious use of hooks.server.(ts|js).

You only have one architecturally weird thing in our current implementation: The frontend process makes credentialed requests to the backend process on localhost. Ideally this would go via a IPC socket.

Using SvelteKit without disabling all of it's features gives you pre-rendered pages with API requests to a traditional backend living in the same host while also allowing client-side navigation. This setup works for us.

[eltigerchino]

Ben has a PR open to address this https://github.com/sveltejs/kit/pull/13444/files would love if people could give it a read and provide some feedback