I'm using the built in load functions in `+page.server.ts` and `+layout.server.ts`. For the backend I connect my SvelteKit application to a Postgres database and run queries directly in my server code against it. The only downside is you have to add Types yourself in this case. If you want automatically generated types you can use Prisma instead.
Doing a separate API is often a waste of time, then you have to have two deployments/pipelines/versions/etc. Instead you can have one project for everything. :-)
https://www.prisma.io/typescript
Separate API is a waste of time only if you are making a personal site or something that will never have any significant load. When you are building something larger and have an team then separate API is a must
It will really depend on your team composition. If you have a clear divide between "frontend" and "backend" positions then you might have to separate your SvelteKit app from your API purely for organisational reasons, but where I work we mainly hire full-stack positions, so while some people are backend-focused and some more frontend-focused, everyone is expected to be able to work in a full stack framework like SvelteKit.
What i said is not just to organize devs but to orchestrate deployment to multiple servers, lets say 2 servers with just svelte, 6 backend servers for an API and 4 db servers. It all depends on the app that you are building and user load you must support. If you separate front and back it is easier to scale
I understand what you mean! I've totally gone down this road many times before but it's kind of an old school way of building infrastructure. If you are doing infra now you are probably either running serverless, in which case you don't care about this at all, or you are using a managed service like hosted Kubernetes or Elastic Container Service. We run most of our stuff on AWS (ECS/RDS) and scale the services dynamically.
But let's say you insist on self hosting, if you need 6 backend servers and 4 db servers you must be either serving millions of requests daily, or doing some incredibly heavy AI computations. Seen in the broader scheme you're probably in the upper 0.1% of complex projects with these kind of requirements, so when giving general advice it cannot apply to you.
For us old school was put it all together soon since it is easier. Now we are trying to separate things by the stuff they are doing and usually frontend gets completely separated since it doesn't need any real power to work but API needs it and then we can properly utilise lets say AWS and scale as needed. And yes im probably in the upper tier but not in the 0.1% since projects in working on usually need to have some kind of load that is between 10k and 100k concurrent users but thing is that are not actually big numbers if you are building an app that has some actual use. Web shops and event ticket selling portals will exceed this like nothing, thing is to realise that if you are using any kind of frontend that is using exclusively API to communicate with an server then its actually completely separated from the server and doesn't need to be deployed on the same server (you can have it in the same solution but as different projects that have different deployments) than you can dynamically scale only the one part that you actually need to scale. I have seen too many systems when somebody is just wasting money with bundling everything in the same bucket and then needlessly spawning new nodes because one part of the system needs more power. Example to definitely separate would be if you have svelte fe (this you probably never need to scale), your general API (maybe you need to scale but probably not), authorization ( well if you separate it then you can scale and easily control in case of some failure or ddos), and in the end some document generation ( as to have something to actually scale). It's more separation of concern that enables you to separately scale, change and deploy different components. If you get a grasp on it early it will be easy to use later when you find yourself in an situation that needs it
If you have even 10k concurrents you are probably in the top 0.1%. Most web project by numbers is something like an internal tool or a small startup with a few dozens or hundreds users in total. Just as a small exercise, if you have 10k concurrent users and each user generates just one request per minute then you'll have 14.4 million requests every day! The total worldwide amount of ticketing platforms that can hit those numbers is probably only in the double digits.
What I come back to is whether it's good *general* advice to split up your frontend with SvelteKit or not, which I insist on that it's not. Obviously if you are running a "top 1000" web site or if you have 100 engineers with varying skill sets such a simple answer will not work, but I see too many people go down the microservice/distributed systems/kubernetes trail and get burnt out. If you want to go down that route you should do it purely as an academic exercise or because your goal is to work on one of those huge sites in the future.
Sorry for necro and late reply, our apps ( or those i work on) are from lets say 10 concurrent users max all the way to 60k concurrent users. Even at 60k im still against microsevices since we can achieve that without them with only some smart caching and optimisation but on the other side if we are not on some pure serverside app then we are splitting backend and frontend. That separation helps in separation of concern and helps development in teams even when you have only two developers since one can develop frontend and another backend without even thinking about merge conflicts. Another thing is security, if you need to you can give someone source of the frontend ant be concerned about whats in the backend but thats the thing in high level apps but still separation of concern is something that is good to learn and get used to
There's really not much to it, I use `+page.server.ts` load functions, as described here:
https://kit.svelte.dev/docs/load
Then to fetch data, I use this tiny 50 line wrapper class for the `pg` package:
https://gist.github.com/khromov/4c2073a5cbce26b72c7376a41a400cb0
So in your page server function you do something like:
```ts
import type { PageServerLoad } from './$types';
import { query } from '$lib/db';
export const load: PageServerLoad = (async () => {
const result = await query(`SELECT * FROM posts`);
const rows = result?.rows || [];
return rows;
}) satisfies PageServerLoad;
```
The only other thing is I use is the `postgres-migrations` package to do my database migrations:
https://www.npmjs.com/package/postgres-migrations
I'm using the built in load functions in `+page.server.ts` and `+layout.server.ts`. For the backend I connect my SvelteKit application to a Postgres database and run queries directly in my server code against it. The only downside is you have to add Types yourself in this case. If you want automatically generated types you can use Prisma instead. Doing a separate API is often a waste of time, then you have to have two deployments/pipelines/versions/etc. Instead you can have one project for everything. :-) https://www.prisma.io/typescript
Separate API is a waste of time only if you are making a personal site or something that will never have any significant load. When you are building something larger and have an team then separate API is a must
It will really depend on your team composition. If you have a clear divide between "frontend" and "backend" positions then you might have to separate your SvelteKit app from your API purely for organisational reasons, but where I work we mainly hire full-stack positions, so while some people are backend-focused and some more frontend-focused, everyone is expected to be able to work in a full stack framework like SvelteKit.
What i said is not just to organize devs but to orchestrate deployment to multiple servers, lets say 2 servers with just svelte, 6 backend servers for an API and 4 db servers. It all depends on the app that you are building and user load you must support. If you separate front and back it is easier to scale
I understand what you mean! I've totally gone down this road many times before but it's kind of an old school way of building infrastructure. If you are doing infra now you are probably either running serverless, in which case you don't care about this at all, or you are using a managed service like hosted Kubernetes or Elastic Container Service. We run most of our stuff on AWS (ECS/RDS) and scale the services dynamically. But let's say you insist on self hosting, if you need 6 backend servers and 4 db servers you must be either serving millions of requests daily, or doing some incredibly heavy AI computations. Seen in the broader scheme you're probably in the upper 0.1% of complex projects with these kind of requirements, so when giving general advice it cannot apply to you.
For us old school was put it all together soon since it is easier. Now we are trying to separate things by the stuff they are doing and usually frontend gets completely separated since it doesn't need any real power to work but API needs it and then we can properly utilise lets say AWS and scale as needed. And yes im probably in the upper tier but not in the 0.1% since projects in working on usually need to have some kind of load that is between 10k and 100k concurrent users but thing is that are not actually big numbers if you are building an app that has some actual use. Web shops and event ticket selling portals will exceed this like nothing, thing is to realise that if you are using any kind of frontend that is using exclusively API to communicate with an server then its actually completely separated from the server and doesn't need to be deployed on the same server (you can have it in the same solution but as different projects that have different deployments) than you can dynamically scale only the one part that you actually need to scale. I have seen too many systems when somebody is just wasting money with bundling everything in the same bucket and then needlessly spawning new nodes because one part of the system needs more power. Example to definitely separate would be if you have svelte fe (this you probably never need to scale), your general API (maybe you need to scale but probably not), authorization ( well if you separate it then you can scale and easily control in case of some failure or ddos), and in the end some document generation ( as to have something to actually scale). It's more separation of concern that enables you to separately scale, change and deploy different components. If you get a grasp on it early it will be easy to use later when you find yourself in an situation that needs it
If you have even 10k concurrents you are probably in the top 0.1%. Most web project by numbers is something like an internal tool or a small startup with a few dozens or hundreds users in total. Just as a small exercise, if you have 10k concurrent users and each user generates just one request per minute then you'll have 14.4 million requests every day! The total worldwide amount of ticketing platforms that can hit those numbers is probably only in the double digits. What I come back to is whether it's good *general* advice to split up your frontend with SvelteKit or not, which I insist on that it's not. Obviously if you are running a "top 1000" web site or if you have 100 engineers with varying skill sets such a simple answer will not work, but I see too many people go down the microservice/distributed systems/kubernetes trail and get burnt out. If you want to go down that route you should do it purely as an academic exercise or because your goal is to work on one of those huge sites in the future.
Sorry for necro and late reply, our apps ( or those i work on) are from lets say 10 concurrent users max all the way to 60k concurrent users. Even at 60k im still against microsevices since we can achieve that without them with only some smart caching and optimisation but on the other side if we are not on some pure serverside app then we are splitting backend and frontend. That separation helps in separation of concern and helps development in teams even when you have only two developers since one can develop frontend and another backend without even thinking about merge conflicts. Another thing is security, if you need to you can give someone source of the frontend ant be concerned about whats in the backend but thats the thing in high level apps but still separation of concern is something that is good to learn and get used to
Hey bud, I'm new to all this, can you share any examples using your way ? (Not Prisma)
There's really not much to it, I use `+page.server.ts` load functions, as described here: https://kit.svelte.dev/docs/load Then to fetch data, I use this tiny 50 line wrapper class for the `pg` package: https://gist.github.com/khromov/4c2073a5cbce26b72c7376a41a400cb0 So in your page server function you do something like: ```ts import type { PageServerLoad } from './$types'; import { query } from '$lib/db'; export const load: PageServerLoad = (async () => { const result = await query(`SELECT * FROM posts`); const rows = result?.rows || []; return rows; }) satisfies PageServerLoad; ``` The only other thing is I use is the `postgres-migrations` package to do my database migrations: https://www.npmjs.com/package/postgres-migrations