async-http

This is great. I had been long looking for something like this in Ruby eco-system. I worked on a Rails app which interacted with a bunch of micro-services and I missed the async-await so much. The problem was, when the app was waiting on API requests, the throughput suffered a lot. We couldn't increase the number of threads a lot, since it increased the memory usage a lot which eventually led to OOMs. I tried to put something together using async-http [0], but it was not very stable. One question would be, how does scheduling work with existing psql and myself db gems. Should the calling code wrap the database calls with `Fiber.await { Fiber.schedule { ... } }`? A framework like this would be very useful when the tech-world is moving towards micro-services, for the good or bad. [0](https://github.com/socketry/async-http)

https://github.com/socketry/async-http is just a new client library. PostRank, Zynga, CloudFoundry were all running async IO in production on Ruby ~10 years ago. CRuby support for non-blocking IO dates back to the mid 2000s. https://github.com/eventmachine/eventmachine actually dates back even further If you're using Unicorn then you've already got Raindrops which gives you a really simple way to do shared metrics across forked processes like in-flight requests to another service or how many of your Unicorns are busy.

Of course it is not an inherent property of a particular language or concurrency model, but it is a property of a particular language ecosystem. As a turing complete language, everything is doable in ruby, but at what cost? Now we are back to trade-offs I listed above. As for async IO in production, looking at the client library, https://github.com/socketry/async-http is barely 3 years old, and probably reached the production-ready state a few months ago, if we are being generous. But good point about service mesh. Moving the circuit breaker responsibility to the service mesh would definitely help in my case, as the sidecar would have all the data points from the 10+ single-threaded ruby processes running in the same pod, and thus could make a much quicker decision.