Broadway es una herramienta construida sobre GenStage, concurrente de varias etapas para crear pipelines de ingesta y procesamiento de datos. Es decir, esta biblioteca nos permite consumir y procesar información de fuentes como un Message Broker (Kafka, RabbitMQ, etc.). Por si fuera poco, viene con una serie de características integradas que nos permiten diseñar nuestros pipelines con una gran flexibilidad: Back-pressure Concurrencia y procesamiento por lotes Rate limiting Varios producers out of the box La posibilidad de crear custom producers Entre otras....

Communicating with external services like a third-party API REST is hard, not only because the contract is designed by someone else. Also, now you need to consider the Fallacies of Distributed Systems. Calls to external services can fail for multiple reasons unrelated to business concerns. You can receive a timeout error, the network can fail, bandwith related errors, etc. However, some patterns exist to build more reliable systems when dealing with network calls....

One of the main problems, when an application grows, is how to keep organized the business logic. Following the “rails way” can conduce to a common result called obese models & obese controllers. This means that your models and your controllers keep growing when you continuously add the business logic in the same place. Another inconvenience is that you are coupling your use cases or business logic to the infrastructure (the framework, the database, and the input interface)....

Maybe, for readability purposes, you prefer to avoid variable rebinding. For example, take this generated test code from mix phx.gen.auth task: test "renders log in page", %{conn: conn} do conn = get(conn, Routes.user_session_path(conn, :new)) response = html_response(conn, 200) assert response =~ "Log in" assert response =~ "Register</a>" assert response =~ "Forgot password?</a>" end It’s completely ok. But, you can prefer something like this: test "renders log in page", %{conn: conn} do response = conn |> get(Routes....

Normally, to talk with an external API we will search some library to do the work for us. Sometimes, this search is infructuous for some of the next reasons: Exist one or more libraries but are unmaintained. There is no library at all. Existing libraries do not fit our requirements. At this point, you could take the following paths. 1 Build a service module in your app Maybe you just need to consume some endpoints and already use some HTTP client like Tesla....