I'd just like to say how dispiriting I find this question considering I how envious of my friends $4k+ computer I was because it had 64mb of RAM and could play C&C Red Alert with absolutely no slowdown. Let that sink in...in the mid 90s, we comfortably fit a Windows GUI and a somewhat sophisticated game into 64mb of RAM and 20 years of "progress" later, we're asking what kind of special accommodations are necessary to handle HTTP requests with the same resources.
Note: It's an entirely reasonable question to ask, which makes it all the sadder.
My favorite comparison is the Apollo guidance computer's memory (though completely different comparison from your GUI and game description). But the AGC is absolutely fascinating.
> 16-bit wordlength,
2048 words RAM (magnetic core memory), 36,864 words ROM (core rope memory)
A Node.js REST API can handle a significant volume of incoming requests with only 50mb-75mb of RAM. For reference here is a load test of handling around 75k-80k reqs/min using node.js containers deployed using Amazon ECS. Each node.js process is basically just doing CRUD operations, accepting incoming JSON, storing it in a database, fetching values back out of a database, and sending JSON back to clients. There is a bit of extra overhead from microservice HTTP fanout to other backend microservices, but the whole stack is very lightweight and 99% of requests are served in under 30ms.
As you can see this workload is only using about 6% of the available memory. For event loop driven systems like Node.js or Nginx, or Go the workload is almost always CPU bound not memory bound:
I’m pretty sure most languages, even interpreted, can run at least small programs in 64MB. If you want to minimize memory usage at all costs, I think you’d want a non-GC compiled language (C(++), Swift and Rust come to mind).
You can forget about Node.js, Python or Ruby for any meaningful app, like a web API. Erlang/Elixir is also iffy, I'm pretty sure. Java, last I check, had a default heap size of 64MB, and does badly on less.
I've written small Go programs that can consume around 15-20MB on low traffic. But they also have huge spikes in memory usage when you have concurrent requests hitting them.
It's rather common for managers to want simple, human-readable reports for information which is already exposed through a REST API.
Setting up a container with a cronjob that, once per day, executes a simple shell script which curls a REST endpoint, parses the relevant information, and sends an email out to a pre-defined mailing list or puts it to a slack channel... Yeah, that's pretty simple to pull off within that memory footprint.
Go is a good example - I have several services that consume ~20MB of RAM so no need for beefy boxes. Although that's why I also chose to use Kubernetes - extremely easy to pack a bunch of services.
Note: It's an entirely reasonable question to ask, which makes it all the sadder.