[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.