Major part of my job is what you would call business development. I reach out to customers, but I also receive e-mails and inquiries about projects. Since we switched from Ruby to Elixir as our tool of choice a couple of years ago, I have been asked many times “Is Elixir the right tool for the job?”, “Should I use Elixir over Ruby/Node.js/.Net/Java?” or “What types of projects Elixir is a good fit for?”. Over two years ago, I tried answering some of these questions in a blog post already published on this web site, but that is a long time in evolving world of Elixir and things did change a lot, including our experience with Elixir in production. Let’s re-evaluate these questions and see when Elixir is a good fit in 2018.

Web applications. Large and small.

I have come to the conclusion that Elixir and Phoenix Framework are very good choices for building web applications of any size. Contrary to our previous stacks, we can scale up and down the infrastructure given to us by framework and tools quite easily. For small, microservice-oriented apps we are able to cut out most of the framework/library features that we are not using with ease.

Large applications do benefit significantly from Elixir (and Erlang/OTP) providing us a way to structure our applications in a way that is unlike a formerly used monolith. We have the flexibility to break things down into libraries, use umbrella projects or otherwise split the project into smaller OTP applications/libraries. This allowed us to manage large code bases easier than before, with dedicated teams focusing on parts of the system without affecting the rest.

Web APIs (JSON and GraphQL)

While building traditional RESTful web APIs with Elixir & Phoenix is easy and fairly enjoyable task, we found out that Elixir ecosystem did develop amazingly good support for building GraphQL APIs. Absinthe is our default library of choice when dealing with GraphQL, and it is very mature and fairly complete implementation of the standard. You can pair it with Apollo on the front-end, mobile clients - or other server clients to give them a lot of flexibility in a way of fetching and manipulating the data.

If you are looking to build GraphQL API, my strong recommendation would be to look into Elixir and Absinthe as one of the very first choices.

Real-time web

Remember Meteor? Phoenix Framework ships with powerful abstraction on top of persistent client-to-server connections (WebSockets or long polling) called Channels. The infrastructure is pretty low-level, and does not give you fancy data sharing between clients functionality out of the box (like Meteor or Firebase do), but allows you to use these abstractions to build tailored system by yourself.

On top of that, already mentioned Absinthe library provides support for GraphQL subscriptions, which is a nice way to track data changes on the back-end and react to them on the front-end. Real-time web with GraphQL and Elixir is really a thing to look into closely.

Whenever you are looking into building web scraper, ad server, payment processor or CQRS-based sytem - Elixir will come in super handy.

Stateful web

Another usage on the web, but a specific one. We know the web is stateless… or is it not?

There are cases when you do need to keep the state on the server. Keep it in memory between requests, during long requests, share it between communicating servers.

There is surprisingly large number of use cases where stateful server is desired. Whenever you build a web proxy, either for HTTP or WebSocket requests, a custom router that dispatches requests to different underlying servers - you need to track state, progress, timeouts of each connection very efficiently. Elixir (and Erlang) is a good choice if you are looking to build such infrastructure for your project.

Another use case for stateful web applications are the real-time web applications where you want to share data between clients, or game backends where you need to track and share state & progress. Elixir comes with OTP primitives such as GenServers and Supervisors, but also extends on the Erlang’s developments with own inventions to make programmer’s life slightly easier.

Event-driven systems or …batch processing

Elixir comes with primitives that do allow you to build event-driven systems, in a similar manner to, say, Node.js. But it also comes with multiple solutions for pub-sub, messaging in cluster of nodes (or within single node) or processing large amounts of data (events?) in batch, asynchronous (or synchronous!) manner.

In fact, the choice oftoolsthatyoucanuse to build event-driven systems, or systems that batch process a lot of data is so large that it might give you a head ache at first. The thing is, there is rarely “one size fits all” when you are dealing with events or streams of data, and Elixir’s community came up with multiple solutions you can choose from - or - build your own on top of them.

The cool thing for me about Elixir is that you may not need complex and difficult to manage tools (say Kafka), or expensive hosted message brokers (say SQS), and you can design and build your own high performance pipeline based entirely on the tools provided by language.

Distributed systems

While perfectly possible to design and build distributed systems in other languages, Erlang/OTP and Elixir make it so much easier in some cases. You can default to use Erlang’s distributed applications architecture for your co-located servers, use lasp/partisan’s rapidly maturing stack or utilize libcluster’s flexibility to build, deploy and manage clusters of Erlang nodes of your own design. Phoenix Framework recently starts innovating here as well, with introduction of Firenest project that I am really looking forward to seeing in action.

Elixir also talks to major queuing systems and message brokers such as RabbitMQ, utilizes Protocol Buffers or talks to IoT devices.

Internet of things, industrial automation, embedded systems

Nerves project is simply amazing. It allows you to build, deploy, push updates to your devices that need to control things in real world. Think drones, automated brewing machines, production assembly lines, stand-alone web cameras or CCTV networks, autonomous robots and many more.

If you want to know more about Nerves, I highly recommend watching a number of talks posted on their web site about the subject.

Nerves is at the moment production ready (and used in production!), it is not just for the hobby projects anymore!

Summary

The thing I like about Elixir is that it gives me and my team possibility to work not just with traditional web applications, but also expand our horizons and develop our skills in different areas.

When clients come to me with projects, I still always think if Elixir is a good fit for the job. I like, however, that I am able to answer “yes” most of the time.

Do you have some Elixir-related project in mind we could help you with? Web or otherwise - we would be delighted to help - the contact details and handy contact form are just below this article.

Post by Hubert Łępicki

Hubert is partner at AmberBit. Rails, Elixir and functional programming are his areas of expertise.