Interacting with external APIs is something almost every real application needs to do. GitHub, Stripe, AWS, Slack—your app is probably talking to at least one of them.

And when you write tests for those integrations, you should avoid hitting the real API. So we mock them.

Great.
Except… how you mock them matters a lot—especially once you turn on async: true.

This post is about the trap I hit while mocking API calls in Elixir tests, why it happened, and how ProcessTree solved it beautifully.

Most people start by using TestServer or Bypass. They work well and are easy to set up.
TestServer’s docs even give a nice example:

Well… not if your tests run asynchronously.

To see why, let's walk step-by-step through a  example.

And here’s what happens when you turn on async:

Because Application config is global state. One test is setting base_url to one TestServer instance, another test sets it to a different TestServer, and your async tests collide. You get requests meant for Test A hitting TestServer B.

Each test should have its own mock server.

Each test should have its own base URL, isolated from others.

This is exactly the kind of problem ProcessTree is designed to solve.

From the docs: "ProcessTree is a module for avoiding global state in Elixir applications."

Step 1: Patch the Client to Read From ProcessTree

🎉 Now the tests run perfectly in parallel.

No collisions. No weird cross-test failures. No guessing why a test intermittently explodes.

Mocking external services is essential. Mocking them safely, especially in async tests, is nontrivial.

With this setup, you can confidently turn on: 

…and enjoy fast, isolated, reliable tests.

Hope you liked it—and I hope it saves you from a few hours of head-scratching like it did for me. 🙌

How ProcessTree Saved My Async Tests

, we care deeply about writing expressive and maintainable Elixir code.
We often look for ways to simplify complex patterns without sacrificing clarity — and one of the most elegant tools in the Ecto toolkit is also one of the most underrated: 

 for a while but have never written a custom type, this post will show you why you probably should.

 is a behavior that defines how a value is 

 between Elixir and your database. The Ecto Type's docs have a great diagram of how this works in practice:


It’s the mechanism behind built-in types like 

That simple ability — to control how data moves between the database and your domain — can lead to more robust designs, especially when you have fixed reference data that rarely changes.

 (one of our open-source projects), we added

 to classify packages.
These categories aren’t user-generated; they’re a fixed, known list that rarely changes.

Automatically load the full struct when fetching data

Let’s look at how developers typically handle this — and how Ecto Types make it better.

.
3. Manually load the category when fetching a package.

 field as virtual on your schema.
This works — until someone forgets to call 

.
You can wrap it in helper functions like 

, but this pattern often becomes repetitive and error-prone.

With a custom Ecto type, we can encapsulate all that logic in a single module:

 the correct struct when fetching from the DB and 

You might wonder how this affects queries.
Good news — it still feels natural:


Under the hood, Ecto will call your type’s 

 function, translating the struct into its stored integer ID.

 – schemas express real domain concepts, not implementation details.

 – no need to manually load or cast fields.

 – impossible to “forget” loading a virtual field.

 – all conversion logic lives in one place.

For small or static reference data, it’s a perfect fit.

Ecto Types are one of those Ecto features that quietly solve a lot of pain points once you start using them. You can check the full implementation of Elixir Observers categories 

.
They help bridge the gap between how you think about your data and how it’s stored, leading to clearer and more reliable designs.

If you’re repeating the same cast or load logic across multiple modules, consider turning it into a custom type.
Your future self (and your team) will thank you.

Fun with Ecto Types

Last month we had the chance to participate once again in 

, the largest Elixir conference in the United States. This year was especially exciting for us at Mimiquate because two of our team members presented talks: myself and 

. Beyond the presentations, we also showcased some of the progress we’ve made with our open source projects and shared our vision for making Elixir even more approachable to newcomers.

My Talk: Accelerating Elixir Adoption with Elixir Observer

 and how we can lower the barriers for developers who are new to the ecosystem. My talk centered on 

, a tool we built to help developers explore Elixir packages more easily.

Instead of jumping between Hex and GitHub to evaluate whether a package is mature or widely adopted, Observer consolidates all relevant information into a single place. But what makes it stand out is the emphasis on 

, which allows developers to process information faster and make more informed decisions.

ElixirConf 2025 – Introducing Elixir Observer

, but since then we’ve added several new features:

 Observer now checks each package’s repository for commits that haven’t been released yet. This helps developers anticipate activity levels and spot upcoming improvements. Each package page now shows how many commits are pending release, with a link to explore them directly.

 To improve discoverability, we introduced a fixed set of categories. Packages are classified automatically using Google’s Gemini based on their name and description. This makes browsing much more intuitive for newcomers.

 Until recently, Observer supported only rigid keyword-based search. With semantic search, developers can now search by concepts, making it easier to find packages even if they don’t know the exact keywords.

Together, these improvements make Elixir Observer a more powerful entry point for anyone exploring the Elixir ecosystem.

Gonzalo’s Talk: Building an Exception Tracker in Elixir

Gonzalo’s talk focused on exception tracking in Elixir. His presentation walked the audience through the journey of handling errors while building products, and how that experience led us to create 

Tower is a flexible package for exception handling and reporting. It allows developers to integrate with any exception tracking provider, making it easier to centralize error visibility across systems.

👉 You can watch Gonzalo’s talk here: 

ElixirConf 2025 – Building an Exception Tracker

Looking ahead, we’re working on introducing Igniter support across the entire Tower ecosystem. This will simplify installation and configuration for developers. While doing this, we also discovered improvements that can be upstreamed into Igniter itself, and we’re excited to contribute back to the tool in the near future.

ElixirConf US is always a special time for us: a chance to connect with the Elixir community in the United States, share what we’ve been building, and learn from others pushing the ecosystem forward. This year felt particularly rewarding as we showcased both 

our commitment to adoption (Elixir Observer)

At Mimiquate, we believe that by sharing our learnings and building open source tools, we can help the Elixir ecosystem grow stronger, more approachable, and better equipped for the challenges ahead.

✦ If you haven’t yet, check out the talks above and give our open source projects a try. We’d love to hear your feedback!

Mimiquate at ElixirConf 2025 & open source updates

We’ve been working on something at Mimiquate that we're really excited to finally share with the community: 

. It's an open-source tool designed to simplify how you discover and select Elixir packages for your applications. We first introduced Elixir Observer during lightning talks at GigCity Elixir and ElixirConf Europe, and now it's ready for everyone to try out!

We love Elixir, and we know that choosing the right packages is critical. However, we've often found ourselves jumping between different websites—checking Hex.pm, then GitHub, reviewing docs, changelogs, and figuring out if the package is actively maintained.

The existing ecosystem’s package manager (Hex.pm) does its main job well—

—but understandably doesn’t focus heavily on user-friendly design or providing detailed insights.

This gap has come up frequently within the Elixir community. And, while the community agreed it's outside the scope of the Hex team, we thought, "Why not build it ourselves?"
So we did.

 Quickly understand if a package is a good fit without needing extensive research.

 Make it simpler for developers new to Elixir to quickly get familiar with the ecosystem.

Attracting developers from other communities:

 A well-designed, intuitive UI can make Elixir feel even more approachable.

As of today, Elixir Observer allows you to easily search for packages and provides detailed package pages that are clean and user-friendly. Each detail page displays popularity and maintenance indicators, giving you an instant overview of a package’s health. Additionally, you’ll find convenient links to essential resources such as the GitHub repository, Hex.pm page, documentation, and changelog. Our focus on usability and thoughtful design ensures that Elixir Observer is both intuitive and enjoyable to use.

We’re releasing Elixir Observer as open-source because we believe collaboration will make it significantly better. We’re already planning:

Better categorization and tagging of packages to improve discoverability.

But we want your input! What would you find useful? How can we make Elixir Observer even more helpful?

, raise issues, suggest new features, or even submit a pull request—we'd love your contributions!
We're excited to build this together with the community and make the Elixir ecosystem more accessible and welcoming for everyone.
Happy coding!

Introducing Elixir Observer: A Better Way to Explore Elixir Packages

 Your package depends on other packages, and their updates can break your package without you realizing it. We published 

, an elixir package to make testing against multiple versions of dependencies fast and simple. Check out 

 showing exactly how to integrate it into your package.

If you create or maintain an Elixir package, chances are it's built on top of other open-source libraries. You can see this clearly in your 

Surface has extensive tests to catch regressions and ensure features work correctly. But what version of 

, your tests uses the dependencies as exactly defined in in 

So, as Surface evolves, new features, bug fixes and refactors are implemented in surface source code, how do you know it still works with 

A great package stays great by multiple reasons but avoiding regressions or having as few bugs as possible is one of them. The sooner you catch issues, the better, the feedback loop is crucial.

Both potentially could have been avoided.

How to test against multiple versions of dependencies

 to make it as easy as possible to test against multiple dependency versions without manual 

 juggling. Blend is a development-only tool, meaning it won’t bloat your production release.

 (an Nx backend), we realized that testing against different versions of 

 was a real pain. We started building a solution to simplify this process, and then we realized this was a problem the broader community could benefit from.

At first, we wondered whether this wasn’t a common practice because it didn’t feel like a real problem or if the problem was real but we were just missing the right tools to solve it easily.

We believe it’s the latter, so we decided to extract 

, you can define a test matrix covering different versions of 

https://github.com/surface-ui/surface_catalogue

https://github.com/surface-ui/surface_form_helpers

https://github.com/dbernheisel/phoenix_seo

https://github.com/Flo0807/flagpack_elixir

https://github.com/mimiquate/slack_request

https://github.com/mimiquate/tower_rollbar

 to demonstrate how easy is to integrate blend into an existing package. Check out these two different approaches PRs:

 - Add Blend with BLEND env var configuration

Test Your Elixir Package Against Different Versions of Its Dependencies

: We built and open sourced a new Elixir package called 

 that provides Elixir Exception Tracking with many pre-built reporting options available, including E-mail, Slack, local ErrorTracker and popular 3rd party services.

The Elixir programming language is well known for it's easy way of building applications that, almost naturally, can deal with and tolerate faults.

 programs (and in turn Erlang and Elixir programs), by design, run as a collection of small and isolated processes supervised by other special processes called supervisors that act when their supervised processes (children) exit abnormally (mostly restarting them based on different strategies).

However, that doesn't mean that one would want to completely ignore any exception in processes running as part of an Elixir application.

Something goes wrong for one or some amount of processes, they terminate their execution abnormally, and a supervisor takes care of re-starting these with clean state. It is truly great that this mechanism makes your application tolerant to the exception, the fact that it contained, isolated, and that it doesn't bring your whole executing application down.

But you still want to be informed about whatever went wrong, so that you can try at a later point in time, understand, troubleshoot and fix whatever needs fixing, to prevent it from happening again if possible or prevent worse consequences.

So, exception tracking and reporting, I think is still very important for Elixir applications as it is for other programming languages.

When it comes to writing code to listen and be aware of all exceptions occurring in a running Elixir application, it's not as trivial as it can be with other programming languages that are naturally single-process. Writing a simple "try-rescue" wrapper in an application "entry point" won't work, because there is no such thing as a main entry or main function.

Any Elixir application is highly concurrent. Several processes will be started concurrently at boot time by the BEAM VM. Not only the main application supervisor's children defined in the 

 file will run concurrently, but potentially also a several of the dependencies listed in 

, may have defined their own "application" that Elixir will also run concurrently along yours.

 behavior can be enough to handle all exceptions happening in processes executing plug calls, i.e. executing the source code that is responding to web requests, like a Phoenix controller action function. However, it won't be aware of exceptions happening elsewhere, in backgrounds processes like Oban jobs, or any concurrent processes part of your supervision tree or dependencies supervision trees, or even unlinked tasks (with 

) started in a controller function itself.

Whether these omissions are a deal-breaker might depend on each one.

They are for me in most use cases if not all. I won't feel comfortable running an Elixir application in production for which I won't be informed of all exceptions, except the ones I intentionally silenced. I think I'd rather be informed by an error tracker first than by a customer.

A second and more general-purpose approach is implementing a logger handler.

For quite some time, in Elixir, there wasn't a well generalized and solid solution for this, until a substantial change landed in Elixir 1.15 with the 

Details probably deserve their own separate article but in summary it means that one can easily define what is called a 

 and listen to all, or a filtered subset of, logged events in the running applications, which include, among other events, exceptions in processes.

This will listen to any exception "crashing" any running Elixir process.

Raised exceptions that are manually handled (via rescue or catch) by application code or your dependencies code, that aren't re-raised won't actually "crash", so it won't land on the logger, unless the handling code manually sends a log message to the logger including the 

An example of these "silent" exceptions are those occurring inside 

 job execution. For those particular situations, hopefully the library emits 

 events with the exception information, which is the case for Oban. That means that in addition to a logger handler you may need a few additional Telemetry event handlers as add-ons for special cases.

Cool. We found a way to listen to any exception occurring in any concurrent process in the whole running application.

All of the above work to listen to exceptions is, in a nutshell, what 

 does, a package we build for ourselves at Mimiquate and open sourced.

At its core it is a universal Elixir exception tracker, that wraps the exception data into a well-defined Elixir struct called a 

 and passes these along to any number of reporters. So we also say is agnostic to reporting destination, meaning it's not coupled with Exception Monitoring Services, E-mail or Slack or any other.

In order to report to one any number of destinations you can depend on separate Elixir packages that we also wrote and published, or write your own.

Set a few Sentry-specific config settings.

Automatic reporting of exceptions will “just work”.

 anywhere you like in your application code, like so:

You need or want to switch service from Sentry to Honeybadger.

config :tower, reporters: [TowerHoneybadger]

Add Honeybadger-specific config, like setting API Key.

Automatic reporting of exceptions continues to “just work” without any changes.

 throughout your application code unchanged.

You are reporting to Sentry and you want to test ErrorTracker while continuing to report to Sentry.

Follow a few ErrorTracker specific configs.

config :tower, reporters: [TowerSentry, TowerErrorTracker]

Automatic reporting of exceptions continue to “just work” without any changes.

Now you will have exceptions reported to both Sentry and ErrorTracker.

Tower: Universal and Agnostic Elixir Exception Tracker

After eight years of growth and evolution, we’re thrilled to unveil a fresh look for our brand, along with an updated website and a brand-new blog. This rebranding marks a key milestone in Mimiquate’s journey, helping us better communicate who we are today and share more about what excites us—especially the projects and events we’re involved in.

When Marcelo and I first founded Mimiquate, it was just the two of us. Our goal back then was simple: create a brand that looked great online and could be easily shown to potential clients as we traveled to conferences. It was essential that the brand reflected our commitment to adapting to our clients’ needs—something we still prioritize today.

One of the things we loved most was our original mascot, the chameleon. It wasn’t just a fun symbol; it represented our core value—adaptability to our clients. Just like a chameleon changes its colors to fit its environment, we prided ourselves on being flexible and responsive to the challenges and requirements our clients presented. However, as time passed, we realized that while the mascot worked well digitally, it became tricky to use in other formats like print. Logos were more complex back then, but the industry has since shifted towards simplicity.

We took a practical approach to our first website, too. Using a $20 template from an online gallery, we customized it to fit our needs. At the time, it was the perfect solution: affordable, quick, and functional, with a fantastic return on investment for our young company.

As Mimiquate grew, balancing branding with the demands of the business became more difficult. Both Marcelo and I were coding full-time, so naturally, marketing efforts took a back seat. Now, eight years later, with a team of 30, we finally have the opportunity to focus more strategically on enhancing the company’s image.

Our original brand started to feel outdated, especially with the industry trend toward cleaner, more modern designs. What once symbolized our adaptability began to feel too complex. So, we knew it was time for a refresh.

For this redesign, we chose to work with the creators of our original brand, Barbudo Estudio, because of the great experience we had with them before. This time, we wanted a more modern, approachable look that reflects our growth while staying true to our core values.

A key difference with this rebrand is that we involved our entire team in the process. As Mimiquate has expanded, we felt it was important for the brand to represent all of us, not just the founders. The result is a fresh, unified look that we’re all proud to share.

Our rebranding didn’t stop at just the logo. We also set out to completely redesign our website to better showcase who we are today and the work we do. To bring this vision to life, we teamed up with our friends at Purple Bunny, who handled everything from design to copy and implementation.

One of the most exciting aspects of the new website is the launch of our blog. We’ll use this space to dive into technical content, share updates on the events we organize and sponsor—including the Elixir Montevideo meetup—and talk about other company-related initiatives. We’re excited to connect with our community in a more personal way through these posts.

Mimiquate's New Look and Blog

At Mimiquate, we are strong believers in the power of in-person community events. There's something unique about being physically present that fosters unity, collaboration, and shared enthusiasm. Over the years, we have seen how events like ElixirConf serve as the heart of the Elixir community, connecting developers, companies, and enthusiasts alike. That’s why, for several years now, we’ve proudly sponsored ElixirConf—and 2024 was no different.

ElixirConf 2024 – More Like LivebookConf!

This year’s conference had us joking that it felt like "LivebookConf," with so much focus on livebooks and their ever-growing influence in the Elixir ecosystem. But in all seriousness, the event was packed with inspiring talks, groundbreaking projects, and fascinating use cases that show the continued evolution of Elixir and its community.

The keynotes were, as always, the heartbeat of the conference, offering deep insights and new perspectives. Here are a few standouts:

: These two titans showcased how to spin up 

 machines to perform parallel machine learning tasks, leveraging Elixir for a seamless experience. This method, coupled with the power of Livebook, opens up exciting possibilities for data scientists experimenting with new models. The prospect of bringing Elixir closer to the world of data science is an exciting development!

: Theo’s talk brought a fresh breeze to the ElixirConf stage. Coming from the JavaScript community, Theo’s presence was a nice reminder of how valuable cross-community dialogue can be. His talk was personal, yet relatable to developers from all backgrounds, and his insights bridged the gap between Elixir and the wider programming world.

: José never disappoints. This year, he reflected on 20 years of web development history while also looking ahead at what's to come. One of the most intriguing parts of his talk was an experimental project (now archived) that explored syncing frontend and backend changes through database replication, offering an alternative to LiveView that collapses layers in a new way. It was thought-provoking, even if the project was just an experiment.

: Closing the conference with an inspiring talk, Justin Schneck explored the potential of household technology and how we can leverage it to enhance mental health. His message was not only technically impressive but also a reminder of the broader, positive impact technology can have on our daily lives.

Beyond the keynotes, there were plenty of other excellent talks to check out, especially if you missed the event:

: These talks demonstrated the growing versatility of Livebook in experimentation, teaching, and more.

: Guillaume took us through a live demonstration of building out Elixir’s type system. It was fascinating to watch such an intricate process unfold live on stage.

: Chris’s deep dive into working with Materialized Views in Ecto brought some exciting database concepts to the forefront of the conference.

: Their talk on how Elixir developers can engineer their career progression and promotions was both practical and motivating—great for anyone looking to level up their career.

: Wojtek’s session on rapid prototyping in Elixir was packed with useful takeaways for developers looking to get the most out of their projects quickly.

As always, we’re already looking forward to next year’s ElixirConf. It’s such an important event for us, and we plan on continuing to sponsor and support it. I’ll be there with my instant camera again, capturing memories and making new friends.

One thing we hope to see more of in the future is a more welcoming atmosphere for people outside the Elixir community. Bringing fresh perspectives, like Theo’s, is invaluable, and we’d love to see even more diverse voices at these events.

Mimiquate Blog

Introducing Elixir Observer: A Better Way to Explore Elixir Packages

How ProcessTree Saved My Async Tests

Fun with Ecto Types

Mimiquate at ElixirConf 2025 & open source updates

Introducing Elixir Observer: A Better Way to Explore Elixir Packages

Test Your Elixir Package Against Different Versions of Its Dependencies

Tower: Universal and Agnostic Elixir Exception Tracker

Mimiquate's New Look and Blog

Recap ElixirConf 2024