A brief history of Fly.io Dashboard frameworks

Today I not only bring you an update but also a short history of our choice of technologies to handle our fly.io dashboard.

In the beginning there was the Rails

Long before I arrived here our Rails monolith ruled it all. From UI pages to GraphQL API it did it all. 10 years ago (in 2020) it quickly escalated to be an app that handled most of our infrastructure so it was hard to get started when you just wanted to do some fullstack kind of work and ignore platform stuff.

Since we already needed GraphQL it felt natural to look into another framework to handle our UI.

React… Maybe?

No, didn’t work, we don’t talk about React here, moving on. You have to sign a non-react agreement to work here.

More rails?

We tried another rails app to be our UI-only. The PoC made us quickly realize that didn’t go really well.

What’s left?

We met Phoenix framework and Elixir. We quickly feel in love and wanted more of it. Mark Ericksen and Chris McCord pulled the first strings to make our LiveView Elixir Phoenix UI. Huge emphasis on “UI”.

Elixir just feels correct for us. We ship apps all over the planet and elixir clusters just work :tm: . It still feels a great decision! As a rule of thumb, fly.io is elixir and api.fly.io is mostly rails.

Back then our Phoenix app was just an app that made a lot of GraphQL queries. Believe it or not we did some tokens magic between Phoenix and Rails for our auth system but that’s gone now we just use boring Phoenix sessions.

More Elixir!

Last year we decided that our Phoenix app would be less of an UI and be the future of Fly.io moving forward. We are not huge into refactoring unless it helps address actual customer issues or improve our platform so we didn’t start a massive project to migrate our things. But lately we’ve been outgrowing rails and wanting to do more Elixir.

As of today we shipped a deletion of several GraphQL dependencies on our Elixir app and will be removing more of it soon. Its just funny how we made modules to convert GraphQL data into Ecto Structs parsing even our string IDs from the API but those are slowly getting removed so our Phoenix app can be a simple and boring Phoenix Monolith.

What does that mean for our Rails API?

It’s not going away. Our CLI still is heavily dependent on GraphQL and I don’t think that’s gonna change any time soon. But I can definitely see that some future stuff is gonna be born at Phoenix because we love it and our CLI would rely more on APIs coming from Elixir or our Machines API.


Thanks for listening for my short history and in case you didn’t realize it was all padding to tell you that we deleted code from our app. See you around!

11 Likes