What I don't understand here: Is the sveltekit app built into an SPA or static site? Or is it running on e.g. node as a second backend that communicates with the rust backend over HTTP? If so, doesn't that quite increase the overhead?
Long answer is: looking at the skeleton code in the repo, it's setup for development to run 2 servers (a server just serving static files for the svelt app PORT=3000, and a server running the API PORT=3001) https://github.com/beeeeep54/rust-typescript/blob/main/backe...
But I have seen people do that but:
- Package it into 1 docker container (or 1 service for lack of a better term) that runs both with a proxy that's only there in "prod" deployment not local development. so inside the container it's 2 processes, but outside it's like 1 selfcontained application
- enable a static server on the API endpoint once deployed. It's usually 1 line in most web framework. Something like `app.serveStatic("/", "./static")`. In this case it's 1 server doing both
- Deploy them as 2 different services that scale and are managed completely independently. Could as well be 2 different teams or even companies doing frontend vs backend development (with that same setup of style. Though probably you won't be working in the same repo then)
then take all that and multiply it by 2 or 4 for all the proxy/path/domain permutations
Serving your frontend through nginx for local development would work, but it's not very ergonomic. I know .NET has a built-in development server for frontend apps so you can use it in both prod and dev, but I think most frontend devs prefer the CDN option especially that it gives their delivery a performance boost and makes it completely independent of any backend.
If I see it correctly here, it's a full sveltekit backend that does ssr, and not just used for serving static files. The +page.ts file has a universal load function so during ssr, the sveltekit backend loads data from the rust backend and later during hydration the client also loads data directly from the rust backend without the requests being proxied through the sveltekit backend.
I'm guessing in production one would proxy all requests through the sveltekit backend (or another proxy) as you mentioned.
Also, if we would run them both in the same location or in a container, wouldn't it be much better to use unix domain sockets for the IPC?
> Also, if we would run them both in the same location or in a container, wouldn't it be much better to use unix domain sockets for the IPC?
Probably in 2006? My understanding was that the localhost tcp stack in linux has been optimized so much, that it's hardly a "network" connection anymore and has no overhead compared to a unix domain. The main difference is that people using unix socket tend to hand roll their communication protocols, but if you're gonna be serving http though a
On my desktop
$ netperf -H 127.0.0.1 -t TCP_STREAM
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
131072 16384 16384 10.00 35464.47
$ netperf -t STREAM_STREAM
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
2304 212992 212992 10.00 32852.21
$ netperf -H 127.0.0.1 -t TCP_RR
Local /Remote
Socket Size Request Resp. Elapsed Trans.
Send Recv Size Size Time Rate
bytes Bytes bytes bytes secs. per sec
16384 131072 1 1 10.00 63506.58
16384 131072
$ netperf -t STREAM_RR
Local /Remote
Socket Size Request Resp. Elapsed Trans.
Send Recv Size Size Time Rate
bytes Bytes bytes bytes secs. per sec
212992 212992 1 1 10.00 122526.23
4608 2304