Hartley Brody

My Thoughts About Fly.io (So Far) and Other New-ish Technology I'm Getting Into

It’s been 5 years since I launched my flask boilerplate project in 2017, and that has been my go-to web stack ever since. I’ve built dozens of web apps with it – both for clients as well as personal projects.

Being an independent consultant, I’m not surrounded by a team of people bringing in different ideas or ways of doing things, so I have to occasionally remember to poke my head up and see what’s going on around me.

I spent some time last year (finally) getting familiar with Docker, and wrote my own “Docker Crash Course” as I learned.

Elixir & Phoenix

This year, my goal is to get used to a totally new language and web stack. One that’s fast, productive and requires writing as little javascript as possible:

  • elixir - a functional language that shares the Erlang VM
  • phoenix - the most productive “batteries included” framework for Elixir
  • HTMX - for dynamically updating page content with server-rendered HTML
  • alpine.js - for managing js state – if you really, really must

I was originally put onto HTMX and Alpine by this article that was posted to HN last November. From the discussion on that article, I found a comment that mentioned this demo from Chris McCord on Phoenix LiveView.

Have a look at how Phoenix(Elixir) does it with LiveView. You simply write everything as a server rendered view and the framework pulls things apart and sends just what changed over a web socket. Its mind blowing how fast it is (can be. Latency is real)

I have no doubt that this style of front-end management is going to be a game changer in the next few years. Of course full-on SPA frameworks will still have their place. But if you aren’t writing the next Google Maps clone, maybe you don’t need all that. It’s made me love web dev again after hating the complexity explosion of recent years. (emphasis added)

https://m.youtube.com/watch?v=8xJzHq8ru0M

I finally got around to watching the talk the other day and was definitely blown away with how elegant that framework makes it to keep a reactive UI using server-managed state. I’m also going through the Elixir introduction and Elixir School to learn the basics of the Erlang-based language.

Fly.io

The other thing that I’m seeing coming up a lot on HN is fly.io, which says

Deploy App Servers Close to Your Users

Run your full stack apps (and databases!) all over the world. No ops required.

The product launched on HN in March 2020 and was summarized by a commenter as

fly.io is really a way to run Docker images on servers in different cities and a global router to connect users to the nearest available instance. We convert your Docker image into a root filesystem, boot tiny VMs using an Amazon project called Firecracker, and then proxy connections to it. As your app gets more traffic, we add VMs in the most popular locations.

It seems like it’s got a lot of buzz, especially since they’re riding the wave of support for sqlite in web apps with products like litestream that back up your sqlite file to s3.

I spent a few hours reading the docs and eventually found this very helpful piece buried near the bottom of their nav. I especially got excited when I saw this piece entitled “Fly.io: the Reclaimer of Heroku’s Magic” make the top of HN.

I’ve been using heroku for years and while some might complain that it has stagnated and mostly stayed the same since the salesforce acquistion, I think that’s been an asset. It feels like exactly what I need, and nothing I don’t – an easy way to run a web app that offers a decent add-on marketplace, and enforces 12factor.net best practices.

I nodded along with this HN comment on the article claiming Fly was reclaiming Heroku’s magic:

After all the chatter this week, I’ve come to the conclusion that Heroku froze at the perfect time for my 4 person company. All of these so called “features” are exactly what we don’t want or need.

I’m really glad Heroku froze when it did. Markets always demand growth at all costs, and I find it incredibly refreshing that Heroku ended up staying in its lane. IMO it was and remains the best PaaS for indie devs and small teams.

But I’m also aware of the bias against shiny new things. I know that it’s dangerous to assume that we figured out all of the answers in 2014 and there’s no need to learn anything new ever again. I do want to jump into some new tech that makes intuitive sense to me at a high level.

But despite how much I want to learn the fly.io platform – it has been a bit tricky for me wrap my head around a good use-case for this type of distributed hosting service.

For one, is the cost. If you want a $5/mo server in 4 places, that’s $20/month, which makes sense. But also, I don’t know when I’d want to pay 4x the hosting costs just to “reduce latency” for most applications. I’d rather spend that on a bigger database or cache server for likely a much bigger performance boost.

They also promote the idea of having a local read replica of your database running alongside each instance of your app, but this complicates the picture for writes (which must still be centralized) and eventual consistency. It seems like this would add a whole new class of bugs, like “I just submitted a form to change a setting and when the page reloaded, it still showed my previous value in the form” – since the write hadn’t propagated to the local read replica yet.

Some commenters seem to think CockroachDB will help solve this problem. It’s certainly interesting that it’s wire compatible with postgres, but I just don’t like the complexity of the mental model that all of these distributed services create.

It seems like it’s a service that’s really geared for apps that can live in a truly distributed way to be “close to the user” and not worry too much about consistent state. From their HN launch thread the founder mentions these use cases

  • image, video, audio processing near consumers
  • game or video chat servers running near the centroid of people in a session
  • server side rendering of single page js apps
  • route users to regional data centers for compliance
  • graphql stitching / caching (we do this!)
  • pass through cache for s3, or just minio as a global s3 (we do this!)
  • buildkite / GitHub Action agents (we do this!)
  • tensorflow prediction / DDoS & bot detection
  • load balance between spot instances on AWS/GCP
  • TLS termination for custom domains
  • authentication proxy / api gateway (we do this!)
  • IoT stream processing near devices

but these all seem like fairly specialized workloads, and not something for the average web app.

I do want to be open to doing things a new way and weening myself off of the stack I’ve practically memorized over the past 5 years. I know it will be slower initially, but if I’m going to continue benefiting from standing on the shoulders of giants, it’s good to hop up onto the taller ones that stand up every few years.

100+ comments on HN