Systems | Development | Analytics | API | Testing

In a world where we glorify fast output and moving on to the next thing, we often find ourselves thinking in happy paths only. Let's be honest, though — errors happen. And when you start thinking about properly modelling and handling them when the project is already in full swing, you are too late. Good errors can help reveal what works and what doesn't work.

If you’ve spent any time debugging slow endpoints in a Phoenix application, you know the pattern: something is slow, you open your APM, you see a big chunk of time attributed to “Ecto” or maybe just “Controller,” and then you go make coffee while you grep through logs trying to figure out what actually happened. With v2.0 of the Scout APM Elixir agent, we’re closing that gap.

If you’ve been on the fence about trying the Ash Framework, this post is for you. We’re going to explore why Ash is a game changer for Elixir developers by building something complex, real, but surprisingly elegant. We’ll create AshTherapy, an AI-powered therapeutic chat service that handles conversations, messages, and user interactions — all powered by Ash. Before we go further, let’s first answer the question: what exactly is Ash?

Cowboy is a small, fast, and modern HTTP server for Erlang/OTP. It particularly shines when handling multiple concurrent connections with minimal overhead. This makes it a perfect choice for building lightweight, real-time streaming services. In this article, we’ll build a tiny real-time text pub/sub server using Cowboy. Our service supports HTTP-based publishing, allowing clients to subscribe using either WebSockets or Server-Sent Events (SSE).

When your application suddenly fails at 3 AM, logs will be your best friend the next morning. But until this happens, we often treat logs as an afterthought. Sometimes there is a discussion on log levels or wording of the message, but we rarely go beyond that. After all, what's so interesting in pushing out a bunch of letters, perhaps with some additional metadata, which we will not use 95% of the time? The Elixir Logger module has us covered well. It's a solid foundation for our basic logging needs.

When you build Elixir applications, you'll likely encounter scenarios where you need to handle large datasets efficiently. Whether you're importing user data from a CSV file, updating thousands of product prices, or synchronizing data from external APIs, performing operations one record at a time can quickly become a performance bottleneck. In this two-part tutorial, we'll start by exploring Ecto's powerful batch update and advanced insert capabilities for handling bulk data operations.

When writing Elixir, most developers quickly get familiar with IO.inspect as a quick way to see what's happening inside their code. But what many overlook is that IO.inspect is far more powerful than just a method that prints a variable to the console. In fact, with the right options and placement, IO.inspect can become a precise, highly targeted debugging tool, one that doesn't interrupt your program flow and works seamlessly with Elixir's functional pipelines.

If you work with Elixir, chances are you've used structs plenty of times and are likely aware of Ecto schema. However, you may not have explored structs in depth or used Ecto schemas beyond the database context. In this post, we'll explore the ins and outs of structs and Ecto schemas.

If you have spent any time working with Elixir in a production setting — or even just building a side project — you've likely encountered a stack trace. Stack traces can appear intimidating at the outset, especially since Elixir's error messages are often more detailed than those in other languages. However, they are a powerful tool for understanding what went wrong in your code. Early in my Elixir journey, I found stack traces to be a bit overwhelming.

With its vast ecosystem, Elixir offers multiple solutions for running things in the background. To a newcomer or even an experienced developer, the variety of options might seem daunting. Some tools that used to be popular have fallen into the maintenance limbo, while others have emerged as default choices.