Is that kind of a container less capable than just about any client (except embedded of course)? Sorry if it's a stupid question. I'm not familiar with web SSR.

Yes, and if you've got a fairly complex website it's unlikely it could render more than a couple dozen rendered requests per second. If you're not rendering and instead getting them from a cache, that would be different of course.

The question makes no sense and your answer is wildly misleading and inaccurate.

A server is not 'rendering' a website the same way a client does.

A couple of dozen requests a second? In drupal in dev mode maybe but even then... I feel like we need to have a bit of a knowledge reset before spouting supposed info about csr v ssr

> A server is not 'rendering' a website the same way a client does.

While this is technically true, there is still "rendering" happening on the server when you JIT-compile JSX/TSX templates and transpile everything from your ES6 modules and includes to HTML/CSS/JS that a browser can parse.

In a sense you're splitting the load between client and server because you're right some stuff always has to run client side (like the actual layout engine work).

Very much depends on the code you are running. If you're running something like React server-side rendering it may not be enough resources - in which case you'll probably want an instance that costs $10-$50/month instead.

Most server-side frameworks I've worked with will perform just fine in 256MB of RAM though. These days I'd expect people to get the best results from Go or Rust, if they want to be able to run on as little RAM or CPU as possible.

I'll keep on sticking with Python!

I know not the same use case, but nginx will serve near 100K requests per second of a static site on a moderately powerful server. Server side generated SPA empowered by K8 solution drops that to a dozen. Those number discrepancies are comical.

I must be too old to enjoy recent resume building architectures....

What does that have to do with kubernetes? Nginx runs fast on kubernetes also.

fly is not based on k8s or docker https://fly.io/blog/docker-without-docker/

they just use docker api, hence why I don't think there is the resource waste typical of k8s

I haven't run benchmarks but speed wise containers shouldn't slow down app requests (except in a few cases with very specific kernels, which I unfortunately experienced in production - but I was told it was just bugs)

I'm assuming Fly.io offering is powered by K8.

fly.io is simply a VM provider. You can achieve the same requests per second there as any VM host. The person you're replying to just has a comically low expectation of performance.