Principles of Elixir Application Development

Intro

Many programmers use the Unix-like system to develop and serve web applications. We often use Unix commands such as: grep, cat, mkdir, ls, ps etc. All these commands have common properties: they solve specific tasks, their utility names are explanatory, they are encapsulated, are idempotent and convenient to use. Unix commands are a process. Since one process has an input and the other has an output, and they can be substituted, it is logical to assume that they can be connected. This approach is called the pipeline.

For example:

cat mix.exs | grep elixir | uniq | sort

1. Read the file mix.exs
2. The input data is grappled by the substring “elixir”
3. Duplicates are removed
4. The input data is sorted and displayed on the screen

The main idea is that Unix commands have many similarities with Elixir and functional programming. We often use the pipeline mechanism in Elixir and our function looks like the Unix command which drags data through a chain of functions, each of which acts as a converter or filter. When I start to create a new service or solve a new business issue, I try to design functions and programs as separate Unix utilities, following the principles below:

1. It is important to understand what you are doing and why.
2. Always ask yourself why this solution was chosen and how it fits into the concept of the system and how other developers will use it.
3. Also important, is the logic of the organization of the code, the context, the names of the classes of modules and of functions.
4. There should clearly be a logical chain that, as a guiding star, paves the way to how to use and where to find a particular function. If there is no clear logic and principles in the organization of the code, the system becomes difficult to maintain and difficult to expand.
5. It is important not to complicate the system when designing like a Swiss penknife, sometimes simple solutions are more reliable, clearer and easier to expand than complex logic.

Now let’s try to implement this principle in real life to solve real problems when we are designing an Elixir Web Application.

Design pattern parameter — Part 1

In this chapter, we use this approach to validate data, prepare and unify for further services.

Railway Oriented Programming — Part 2

This pattern helps create the structure of our program as a specification, handle errors, solve nested case statements, and simplify complex logic with the SOLID principle.

If you like the first and second part, please give me your positive feedback to inspire me to continue writing.

Feature toggle — Part 3 (in progress)

This chapter covers the principle used for the introduction of new functionality partials for specific users, the turn-off/on function, the A/B test or the test complex functionality in production.

Protocol — Part 4 (in progress)

One of the ways to create the pattern Factory for Elixir is to use Protocol, in this chapter we will see how to do it.

Presenter — Part 5 (in progress)

This pattern helps us prepare and simplify data for our view, hide if, case statement and organization code.

GenServer organization — Part 6 (in progress)

This chapter introduces some principles on how to organize our GenServer, what type of mistake we can make if we don’t understand how GenServer works.