3 ms·

The short answer is: Yes 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 fi

The short answer is: Yes 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/backend/.env 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

Cshelton 1y ago
We do something similar, in Dev you have a "dev" server and an API. In Prod, we use a CDN to server the static files using AWS ALB and Cloudfront.
- eddythompson80 1y ago
  Yeah, it's pretty common pattern. Especially if you're doing active frontend development as hot/auto-reloading of the page comes standard with all dev servers and it's generally what you want. 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.
sureglymop 1y ago
Thanks for all the details. I cloned the repo now to take a look. 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?
- eddythompson80 1y ago
  Yeah, you're probably right if you want ssr. My understanding was that most ssr frameworks have ssr as optional and people fight about the tradeoffs between page load time (better with ssr) vs rps per CPU core (better without ssr). I'm not sure if that's the case with svelte. > 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 so pretty close
  - sureglymop 1y ago
    Quite interesting! I get similar results on my machine. But let's also measure latency which is what should show the protocol stack overhead: $ 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 But I would agree now that it probably doesn't matter for most applications.

Cshelton 1y ago

We do something similar, in Dev you have a "dev" server and an API. In Prod, we use a CDN to server the static files using AWS ALB and Cloudfront.

eddythompson80 1y ago
Yeah, it's pretty common pattern. Especially if you're doing active frontend development as hot/auto-reloading of the page comes standard with all dev servers and it's generally what you want. 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.

sureglymop 1y ago

Thanks for all the details. I cloned the repo now to take a look. 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?

eddythompson80 1y ago
Yeah, you're probably right if you want ssr. My understanding was that most ssr frameworks have ssr as optional and people fight about the tradeoffs between page load time (better with ssr) vs rps per CPU core (better without ssr). I'm not sure if that's the case with svelte. > 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 so pretty close
- sureglymop 1y ago
  Quite interesting! I get similar results on my machine. But let's also measure latency which is what should show the protocol stack overhead: $ 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 But I would agree now that it probably doesn't matter for most applications.