4 ms·

Great write up, but I’m surprised by SvelteKit being described as full stack. It doesn’t seem to offer anything around normal back-end functionality. I’ve norma

Great write up, but I’m surprised by SvelteKit being described as full stack. It doesn’t seem to offer anything around normal back-end functionality. I’ve normally understood full-stack to refer to a framework like Ruby on Rails.

Ameo 5y ago
It's definitely full stack; it has endpoints[1] which are just arbitrary API endpoints where you can implement any logic you want (talk to a database, perform conditional logic, etc.). It may not be a fully-loaded solution like rails, but minimalism can have its own benefits. [1] https://kit.svelte.dev/docs#routing-endpoints https://kit.svelte.dev/docs#routing-endpoints
- mathnmusic 5y ago
  How do you run background jobs (either schedule-based or one-off like sending emails)? How do you hold a websocket channel with the client to push real-time updates? IMHO, "Full stack" means a lot more than "can talk to the database".
  - nicoburns 5y ago
    Perhaps it means something different to the Ruby community. But I've most commonly seen "full stack" used to simply mean "both frontend and backend". So if it's running code on the server and the client then it's full-stack.
  - slantyyz 5y ago
    For the background jobs, you can implement that in the hooks file using your node scheduling library of choice.
- xcambar 5y ago
  SvelteKit enables the BFF (backend for frontend) pattern nicely, meaning it can proxy and stitch together your actual API, exposing SPA-specific endpoints. In the other hand, I don't see how you could use it as a primary backend, it just does not support anything beyond routing. Which is nice, not every tool should do everything (on the contrary) but it is important that the developers are not mistaken with regards to what SvelteKit is fit for as a backend.
square_usual 5y ago
It's "full-stack" in the sense that it's not only client-side - it's more like next in that you have code that lives on a server and can respond to client invocations, which is useful if you want to do server-side rendering and so on. It has some neat payoffs - you can use cookies for auth even if your frontend lives on a different domain, because the frontend server can read those - but IME it's a pain if you just want an SPA, and despite what most of the Kit community thinks, those are still pretty useful. You can't SSG an E2EE chat app.
qbasic_forever 5y ago
It has a backend component, you use an adapter to run it on edge/lambda services like cloudflare, or plain old nodejs. In usage it's kind of murky (by design) where the exact delineation is between code running on the frontend and code running on the backend.
midrus 5y ago
Because for some folks being able to execute JavaScript in the backend is enough to consider it a backend framework. That gives you an idea of how deep the backend knowledge is some times. Scary.
l-lousy 5y ago
He mentions using Rust/Rocket and SQLite in the article, I think it was just focusing on the front end library

Ameo 5y ago

It's definitely full stack; it has endpoints[1] which are just arbitrary API endpoints where you can implement any logic you want (talk to a database, perform conditional logic, etc.). It may not be a fully-loaded solution like rails, but minimalism can have its own benefits. [1] https://kit.svelte.dev/docs#routing-endpoints https://kit.svelte.dev/docs#routing-endpoints

mathnmusic 5y ago
How do you run background jobs (either schedule-based or one-off like sending emails)? How do you hold a websocket channel with the client to push real-time updates? IMHO, "Full stack" means a lot more than "can talk to the database".
- nicoburns 5y ago
  Perhaps it means something different to the Ruby community. But I've most commonly seen "full stack" used to simply mean "both frontend and backend". So if it's running code on the server and the client then it's full-stack.
- slantyyz 5y ago
  For the background jobs, you can implement that in the hooks file using your node scheduling library of choice.
xcambar 5y ago
SvelteKit enables the BFF (backend for frontend) pattern nicely, meaning it can proxy and stitch together your actual API, exposing SPA-specific endpoints. In the other hand, I don't see how you could use it as a primary backend, it just does not support anything beyond routing. Which is nice, not every tool should do everything (on the contrary) but it is important that the developers are not mistaken with regards to what SvelteKit is fit for as a backend.

square_usual 5y ago

It's "full-stack" in the sense that it's not only client-side - it's more like next in that you have code that lives on a server and can respond to client invocations, which is useful if you want to do server-side rendering and so on. It has some neat payoffs - you can use cookies for auth even if your frontend lives on a different domain, because the frontend server can read those - but IME it's a pain if you just want an SPA, and despite what most of the Kit community thinks, those are still pretty useful. You can't SSG an E2EE chat app.

qbasic_forever 5y ago

It has a backend component, you use an adapter to run it on edge/lambda services like cloudflare, or plain old nodejs. In usage it's kind of murky (by design) where the exact delineation is between code running on the frontend and code running on the backend.

midrus 5y ago

Because for some folks being able to execute JavaScript in the backend is enough to consider it a backend framework. That gives you an idea of how deep the backend knowledge is some times. Scary.

l-lousy 5y ago

He mentions using Rust/Rocket and SQLite in the article, I think it was just focusing on the front end library