In this two-part series, you’ll get a comprehensive overview of everything you need to know to test your LiveView applications in Elixir. In Part I, I’ll introduce you to LiveView testing guidelines and you’ll write some flexible and elegant LiveView unit tests. In Part II, you’ll write interactive LiveView tests that validate a full set of live view behaviors.
Logs are an important part of your application and logging shouldn’t be one of the last things you think of. You should configure your log system, formatter, and style as soon as you start the development of your app. Also, do your best to document the process and share how it works with the rest of your team. In this article, we’re going to demonstrate how logs work in Elixir. We’ll jump into Elixir’s Logger module, which brings a lot of power to logging features.
In today’s post, we’ll look at two Elixir HTTP client libraries: Mint and Finch. Finch is built on top of Mint. We’ll see the benefits offered by this abstraction layer. We’ll also talk about some of the existing HTTP client libraries in the ecosystem and discuss some of the things that make Mint and Finch different. Finally, we’ll put together a quick project that makes use of Finch to put all of our learning into action. Let’s jump right in!
Erlang & Elixir are ready for asynchronous work right off the bat. Generally speaking, background job systems aren’t needed as much as in other ecosystems but they still have their place for particular use cases. This post goes through a few best practices I often try to think of in advance when writing background jobs, so that I don’t hit some of the pain points that have hurt me multiple times in the past.
In today’s post, we’ll learn about Mnesia, see when you would use such a tool, and take a look at some of the pros and cons of using it. After covering the fundamentals of Mnesia, we’ll dive right into a sample application where we’ll build an Elixir application that uses Mnesia as its database. Let’s jump right in!
With a special thanks to Aleksandar and Unai, we’re happy to announce AppSignal for Elixir 1.13.0, which includes our all-new LiveView instrumentation helpers and updated typespecs. If you’re not an AppSignal user yet, make sure to check out the product tour and see how errors, performance, host metrics and triggers all come together in one tool.
Configuration has long been a hot topic in the Elixir community, and luckily, in the recent months, there has been a great deal of thoughtful work put into making this problem an easier one to solve. Today, we’re going to show you how to migrate from an Elixir application that has been configured with the widely used config/*.exs files at compile-time, to an application that instead uses environment variables for configuration and is configured at runtime.
Elixir describes itself as "a dynamic, functional programming language designed for building scalable and maintainable applications." Although it's a relative newcomer, Elixir is built on top of the functional programming language Erlang. Elixir is capable of using any Erlang library, and is ideal for use cases such as web development and distributed and low-latency systems. The power, dynamism, and feature-rich toolset of Elixir have made it somewhat of a "cult classic" among programmers.
In today’s post, we’ll learn what gRPC is, when you should reach for such a tool, and some of the pros and cons of using it. After going over an introduction of gRPC, we’ll dive right into a sample application where we’ll build an Elixir backend API powered by gRPC. Let’s jump right in!
Elixir 1.10 was recently released, and with that release came a little-known, but very interesting feature—compiler tracing. This feature means that as the Elixir compiler is compiling your code, it can emit messages whenever certain kinds of things are compiled. This ability to know what’s going on when Elixir is compiling our code might seem simple, but it actually opens up a lot of doors for opportunities to build customized compile-time tooling for Elixir applications.
