Hacker News Reader

Comment by ledgerdev | Hacker News Reader

Fly.io is more exciting for me because it's edge app servers and it terminates web sockets. I've been envisioning a live-view like framework, or heck even a regular old rest api, where the client connects to the fly.io server with a single request then the app server makes a request to N number of back end processing servers using an efficient protocol like grpc.

View on HN

The only missing piece for fly.io is data layer. The given redis is only for caching purpose. Once there is a managed distributed data store add-on, it's done. It's very likely liveview will need to hit database. Right now pubsub with redis adapter is the easiest solution for cross-region phoenix application (well, phoenix IS my application!)

It is cool, but it does not scale to zero, so if you have N services you will end up paying for at least N instances.

That's a good thing actually since it means you never have cold starts (unlike Google Cloud Run). Their micro instances cost like $3-4 which isn't that much.

It should be an option in my opinion, as cold start time could vary a lot by which image and runtime you are running, if is a Java app or a statically linked Rust program. I have a bunch of very small and simple services, which I run on a single VPN. Moving to fly.io would mean to pay various time more. I tried that, and the service is nice indeed, but not for me I guess.

Reply on news.ycombinator.com