For the images case, I suggest streaming is not useful. You'll need it all in memory at some point to do the processing. I'm not actually disputing that streaming can be useful, I just really do think it's far more specific than you do, but it's fine. It's an interesting topic. Agree to disagree, its complicated after all.
In the case you're deliberately choosing to do streaming video processing, yep, you've set up a requirement that means streaming is non-negotiable. Totally get it. I would suggest though that again this is really quite specific and not reflective of most folks looking to put a production web service online. For sure not disputing your real-world service, again, just how much it reflects Nim's most pressing shortcomings is all. Regarding the "Wasn't the point of Nim to be good at everything?" section, I think how you architect things is not really a language thing. It seems simpler to me to have a web service just doing API calls and a job queue with a Nim service pulling from the queue. Got more work? Spin up more workers. I can see the argument that keeping it in the handler is nice. Once again, different strokes for different folks, not really a Nim thing to me. As for the specifics of streaming video, it's just hard to communicate well in text. Obviously everything gets complex. Lets say you're just out to serve large files, well Range is perfect. Lets say you are serving video, but to native clients, again Range can be perfect. If the web is inflicting things on you, well, ok now you have hard requirements that mean you have less choice. Again though, we're starting to perhaps not be in the +- one standard deviation of a production web service requirements perhaps. In your experience clearly it is, but I disagree. Most stuff is crud or RPC or dump file serving. All of which can be done without ever needing streams. > Why is your answer to all of these things to use another service? I'm not trying to say that, I just mean when building a real web service it's valuable to find super high-leverage things you can offload from your own servers. Using an object store and load balancer is so flexible, powerful, cost effective and pleasant its just hard to justify making a service more complex out of a simple desire not to use them. And I say this as someone who would never touch most deps out of knowledge of the long-term pain. > In fact, I tried most of them behind Nginx as well. Putting my server behind > Nginx doesn't change the fact that it leaks memory or has poor performance Yeah, you're really right about this I would be mega frustrated by poor performance / memleaks / just any kind of unreliability. It's the kind of thing that really drains programmer happiness. > Please do not insult me by suggesting that I don't know what it takes to run > a production service. This was just a "you" meaning "the reader" not "you" personally. Sorry I was careless in writing that, I kind of lost focus on who I was talking to. No offense intended.
