Moving to Elixir and Phoenix

If you’ve been following the conversation in our Slack, you’ve probably seen that we’re shifting our API away from the Ruby on Rails stack.

We’ve made the decision to migrate to Elixir and Phoenix, and to make this our top development priority. This obviously sets back the timeline we laid out in our 90 days post, but does so at the benefit of laying a great foundation for many of the upcoming features we discussed previously.

elixir-phoenix

New to Elixir and Phoenix?

The best place to start learning the Elixir language is Programming Elixir by Dave Thomas. The best place for the Phoenix framework is Programming Phoenix by Chris McCord, Bruce Tate, and José Valim. Both books are on offer from The Pragmatic Programmers.

This video featuring José Valim’s talk at Lambda Days back in February of 2016 is a pretty good introduction to Phoenix:

So what’s the justification for the switch, when we have so many high priority items already on our roadmap?

If you’re pushing Rails to be more scalable or more interactive, you’re not alone. You’re going to find Phoenix powerful and interesting.

Programming Phoenix

Scalability and speed

Code Corps by necessity is likely to remain a lean operation for years to come. Many of you know that we fund our operations today with consulting work, and only one of us has the benefit of being considered full-time on the project. But we’re also focused on maximum impact, which means having a mind for scale that a small team can realistically achieve.

WhatsApp is the go-to scalability example for Phoenix fans for obvious reasons. Although built on Erlang specifically, WhatsApp was able to achieve 2 million simultaneous connections to a single node. Now, we’re not building an SMS replacement, but we do need to plan to operate at scale.

And how about team size? Well, at the time of the $19 billion acquisition, WhatsApp’s team was only 25 engineers. Since the acquisition, their user base more than doubled, but the engineering team only scaled to 40 total engineers. This is a testament to the architecture that the Erlang VM enables, both in terms of the bare metal and the software’s architecture itself.

Today, Phoenix is able to handle 2 million websocket connections on a single server. Granted, the machine they’re using had 40 cores; but to operate at even a tenth of that scale on, for example, Digital Ocean could cost us $80/month without much extraneous overhead.

microseconds

And Phoenix is extraordinarily fast. How many frameworks do you know that can measure response times in the µs? That’s microseconds. I haven’t seen a µ since my physics days. Those fast response times equate to a better user experience and happier developers. Much of my Rails consulting time has been spent working on performance improvements that I mostly get for free in Phoenix.

Upcoming features

Your imagination building products should never be hamstrung by your technology. There are a number of upcoming features – including a redesign of tasks/issues in the Code Corps UI – that were going to require a lot of boilerplate and heartache with our existing API. In fact, some existing bugs might not have even happened if we’d had some stronger reliance on channels from the start.

Community and excitement

Picking technology trends is a lot like picking stocks. You’re really unlikely to time the market well. And you’re probably better off doing some kind of value investing and holding long. Diversification also doesn’t work so well when you’re picking cornerstone technologies.

Personally, I tend to be pretty slow to pick up on trends. But something feels special about this present moment with Elixir and Phoenix. It feels like an inflection point.

There appears to be some brain drain away from Ruby and Rails and into Elixir and Phoenix. People I respect deeply like Dave Thomas and James Edward Gray are growing increasingly enthused about and invested in this ecosystem. A core tenet of mine – and of Code Corps itself – is to care about people over code. And though I’ve been historically productive in Rails, it’s hard not to see where my community is headed.

The discussion level in our Slack also ticked noticeably upward with the possibility of a switch. Riding a wave of passionate new enthusiasts has its upsides.

Similarly, there don’t seem to be many obviously well-known production apps using Phoenix yet, or at least not many that are entirely open source. There is a Trello clone that has 1,084 stars on GitHub as of this writing.

This fact presents as an opportunity for us. As we scale, we can provide a window into a production application for the Elixir/Phoenix community. And being an app that’s focused on helping open source grow, we seem to be uniquely placed to help this community that already cares about open source.

Architecture and philosophy

In 1967 the computer programmer Melvin Conway introduced an idea now known as Conway’s law:

organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.

Coming to Elixir also allowed me to consider a similar notion: the communication structures that you design can drive the design of the organizations that maintain them.

The nature of Elixir as a functional programming language, along with Phoenix Presence and its bright future in designing microservices, makes for a worthwhile thought experiment. How might an organization that builds Elixir apps be uniquely different? Code Corps – by necessity – needs to have a flatter hierarchy in its organization and more modularity in its code. If the organization’s own structure is coupled too tightly to the architecture it produces, then we may not be able to avoid unintentional bloat.

Consider most object oriented programming languages like Ruby. While the abstractions that inheritance provides can be powerful, this very hierarchy – at scale – can lead to an organization that mirrors those hierarchies. Ruby on Rails undoubtedly mirrored the organizational structure of Basecamp. But did the adoption of Ruby on Rails by so many startups then drive those same startups to structure themselves like Basecamp? Seems reasonable.

In order for teams to collaborate, knowledge of the system needs to be abstracted away into higher-order understanding. When we build service oriented architectures, we may unwittingly also be building the future APIs for team leaders and project managers. We’re designing the collaborative interfaces between them.

This presents a challenge for the organizational architect who wants to keep their team small and agile. The deeper your software’s hierarchies, the more non-obvious its abstractions, the heavier your team’s load. If you also want to grow your application – build more features or more advanced features – you don’t want to be stuck in a negative feedback loop of needing to grow your team to keep pace.

In contrast, Elixir and Phoenix enable more isolation, more concurrency, and less abstraction and its associated cost of understanding. Diving into a piece of an Elixir program and inspecting it and grokking it is remarkably easier than in an object oriented program of similar size. If we expect our team to work asynchronously and be capable of tackling small batches of functionality without blocking each other, then our very architecture helps make this vision much more realizable.

So, what’s the plan?

First, we need to finish our API documentation work on the Rails app. We’ve closed out every issue in the Rails GitHub repository that doesn’t involve documenting the API. Those issues have moved over to our new Phoenix repository.

Outline the MVP for the new API

My next step, along with the core team, is to outline what we’re bringing over to the new API and in what order. We need to figure out how to avoid porting features that may not be required in the new API. We’ve already done some work outlining libraries that we can use.

Look out for an epic on our new Phoenix API’s GitHub repo that breaks down the next steps in some more detail. For now, if you’re eager to help, focus on helping us wrap up the API documentation, and then look into the PragProg books I listed above and start diving in. Our goal is to transition to the new API in the next 3-4 weeks.

As always, if you have questions or concerns, post them here and we’ll be happy to discuss.

Enjoyed this post?

Our best content on open source, social good, and building products. Delievered each week for free.