We've been shipping apps for many years now, and every time around we're frustrated by a rudimentary routing layer. We think a proxy/CDN can do a lot for devs, and Fly is an early look at the power a smarter routing layer can give to developers.
Fly connects visitors directly to apps, handles all the chores, and provides edge-level middleware to help devs ship features faster. It's designed to run in place of local load balancers like nginx and haproxy, and works as both a load balancer and CDN for dynamic apps (we have servers in 6 datacenters, more soon).
For me, the most interesting part is the middleware, and this is what we expect to really matter long term. You're probably familiar with local app middleware to provide auth, modify content, do analytics, etc, etc. Most of these can actually run at the edge, and Fly currently has middleware for:
* Server side Google analytics
* Identity Aware Proxy (require auth to even load an app)
* Geo data / connection speed information as headers
* Session cookie knowledge
* Routing rules
You can mix and match these. If your app is getting DDoS'ed from a botnet in China, for example, you can use the geo data middleware + a routing rule to send all traffic from China to a higher capacity. backend. Or, you can extract a user_id from session cookie and send it to Google analytics. Or, send authenticated users to one backend (like your app) and anonymous users to another (like a static site hosted in GH pages).
This is something we've wanted for a really long time, we've worked on Ars Technica, Compose, and even a bunch of low volume apps that would have been better with a service like this. Traffic routing is really powerful if applied properly, and we're hoping to give any developer the same flexibility as they'd have at one of the big 3 tech companies (who tend to build all this themselves).