[sureglymop]

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?

[eddythompson80]

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/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

[sureglymop]

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]

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]

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]

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]

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.