🔎

    Building distributed apps: second approximation

    Erlang/OTP,  Elixir,  Programming,  Functional Programming,  Distributed systems

    This article is the final one of the series about distributed reactive apps in Erlang/Elixir. In the first article you will find the theoretical basis of reactive architecture. The second one illustrates the main templates and mechanisms of building such systems.

    Today we will address the questions of code base development and projects development in general.

    Building distributed apps: first approximation

    Erlang/OTP,  Elixir,  Programming,  Functional Programming,  Distributed systems

    In the previous article we have addressed the theoretical basics or reactive architecture. Now it’s time to talk about data flows, ways of implementing reactive Erlang/Elixir systems, and message exchange patterns included in them:

    • Request-response
    • Request-Chunked Response
    • Response with Request
    • Publish-subscribe
    • Inverted Publish-subscribe
    • Task distribution

    Building distributed apps: zero approximation

    Erlang/OTP,  Elixir,  Programming,  Functional Programming,  Distributed systems

    These days, the world is moving fast. Progress constantly creates new technological challenges. Information systems architecture should be flexible enough to respond to new requirements and evolve. In this article, we are going to talk about event-driven architecture, concurrency, parallelism, asynchrony, and how to live in peace with all that in Erlang.

    Erlang/Elixir solutions: struggle for quality

    Erlang/OTP,  Elixir,  Programming,  Functional Programming

    Today we are going to talk about logs, quantitative metrics, and how to observe them in order to increase the team reaction rate and reduce the system waiting time in case of an incident.

    Erlang/OTP as a framework and ideology of developing distributed systems provides us with regulated approaches to development, proper tools, and implementation of standard components. Let’s assume that we have exploited OTP’s potential and have gone all the way from prototype to production. Our Erlang project feels perfectly fine on production servers. The code base is constantly developing, new requirements are emerging alongside with functionality, new people are joining the team. Everything is, like…fine? However, from time to time something might go wrong and any technical issues combined with human factor lead to crash.

    As you just can’t have all the bases covered and foresee all the potential dangers of failures and problems, then you have to reduce the system waiting time via proper management and software solutions.