Less Glue, More Product: Why Elixir Shrinks Architectural Complexity

I’m very excited that this year’s StackOverflow Developer Survey showed quite a few mentions of Elixir, Erlang and Gleam. Elixir is one of my favourite ecosystems, and it always feels good to see that a growing number of developers share my enthusiasm.

Most of you know me as someone building apps and libraries for iOS, the Mac and really any kind of gizmo that has a battery and can be programmed in some way.

The thing about building apps is that they often require some kind of backend service to support part of the experience. Be it to retrieve data from an API, some authentication mechanism or more complex features like real-time multiplayer edits, etc. As soon as you have multi-user features or any part that needs to ‘meet the world’, you need a backend.

If you’re not already a backend/full-stack veteran, choosing an ecosystem for the backend is not easy. One needs to take stock of one’s goals and constraints, consider languages you already know or you’re willing to learn, navigate a noisy landscape of content creators pushing for technology choices that result in most clicks or engagement. Often the loudest recommendations aren’t true passion but what drives clicks, so discerning your own trade-offs matters.

This post is very demure and mindful by comparison and I would like to share my belief that if you’re an indie/solo developer or a small team, you should strongly consider Elixir as the ecosystem for your backend components.

The BEAM plus its well-designed syntax lets you stay within a single app longer - no early need for external queues, job systems or orchestration services.

In other words, with a handful of well-established libraries, one can go a long way with just the one application.

It’s very common for established frameworks to need you to add a queue or some kind of bus messaging system, caching or a dedicated job or workflow orchestration engine very early in the life of your application. Think frameworks like Django, Rails, ASP.NET, even very young ones like Vapor require multiple service dependencies for core functionality.

Remember, my recommendation is not absolute. As I outlined above, you’d want to weigh your trade-offs before making a choice. To escape the complexity of juggling multiple systems, one may also be tempted to reach for heavily managed solutions or lambdas.

However, if you prefer to be in control of your stack, your data and your users’ data, you’re probably going to build something to support your app or service and as solo developers, one of our most costly resources is time. Every single thing that we need to do that doesn’t generate value is likely a distraction.

Consider for a second that you want to send a “welcome” email with tips on how to get started to someone who just signed up for your app. You probably need some kind of asynchronous way to do that so it doesn’t slow down the actual signup process. With some frameworks, you’d have to install a job runner, or start a dedicated process just to be able to execute some work on the background. Just with this tiny feature, the complexity of your backend explodes to include a whole new thing that will have it’s own way of being configured, monitored and troubleshoot.

It’s the equivalent of getting a “Failed to produce diagnostic for expression;” while all you want is to add a small feature that will delight your users (fellow Swift developers would recognise what I mean).

All these capabilities come built-into the architecture of a BEAM application. Phoenix ships a lot out of the box without opaque ‘magic’. You can cache, you can run jobs, you can orchestrate entire workflows and even go as far as to spin up an ephemeral virtual machine in order to execute a computationally intensive workload. All that, in the same application as your REST API.

That runtime flexibility also enables advanced tooling e.g., agents in LLM integrations can introspect app state live - Checkout Tidewave!

In fact, if you’re willing to invest a bit more time upfront into “the learning curve”, the Elixir ecosystem has frameworks like Ash which make an entire category of server applications a matter of a few declarative modules. You read that right, you can get a REST or GraphQL API + Storage + Authentication for your app just by describing what it does, rather than writing all the code.

My developer career started more than 16 years ago as a .NET developer. It was my only “tool” for many years before I ventured into other ecosystems. Go, TypeScript and Python have all provided for a lot of fun and functionality over time. When I discovered Elixir back 2022, it changed everything for me and honestly, I haven’t looked back. By eliminating architectural complexity and decreasing code maintenance, it’s a very significant multiplier for productivity and “developer happiness”.

It goes beyond backends for apps too, did you know that programming embedded devices or orchestrating a fleet of IoT gizmos doesn’t have to get on your nerves?

Here is a short selection of Elixir resources that, I believe, will help you get started and connect with the community.

• Mike and Nicole from The Pragmatic Studio have excellent tutorials for both Elixir and Phoenix https://pragmaticstudio.com/
• The Elixir hashtag on Mastodon and Bluesky is #ElixirLang
• The Elixir forums https://elixirforum.com/
• Exercism also has an excellent Elixir track https://exercism.org/tracks/elixir