Whether it’s a large Phoenix application or a smaller service running only Plug and a couple of routes, background jobs are usually part of the stack. Oban has been rock solid for us for years.

One thing we also really like is Oban Web. It gives you visibility into your queues, workers, retries, failures, and everything else you need to understand what your jobs are doing.

That’s completely reasonable — Oban Web is built for Phoenix applications and integrates beautifully there. But not every project we build needs the full Phoenix stack.

At Mimiquate, some of our internal tools and smaller services are just Mix applications with Plug for a simple UI. In those projects, pulling Phoenix just to get a jobs dashboard felt unnecessary.

 a way to run Oban Web as a standalone application, and it works great too. But that means another application to deploy, configure, and maintain.

Ocelot is a lightweight dashboard for Oban.

Understand what’s happening in your background processing system

No job controls. No advanced management features. No attempt to replace Oban Web.

The goal is simply to provide visibility for projects that don’t use Phoenix and don’t want the operational overhead of running a separate dashboard application.

Right now, Ocelot focuses mostly on visibility.

That wasn’t really a philosophical decision as much as a practical one.

When we started building it, the immediate need was simply understanding what was happening inside our queues.

Most of the time, when debugging or monitoring smaller systems, we just wanted to answer questions like:

So the first version focused on making those answers easy to access while keeping the implementation small and straightforward.

Over time, we’ll probably add actions and more management capabilities as we need them ourselves.

But for now, keeping the scope focused has worked well.

One thing we’ve learned over time is that smaller Elixir applications benefit a lot from staying small.

Sometimes a Plug application with a couple of routes is all you need.

Adding Phoenix just for one dashboard page can feel like a lot of extra surface area — especially if the rest of the application is intentionally lightweight.

It’s not trying to compete with Oban Web. In fact, if you’re already running Phoenix, Oban Web is probably still the better choice.

We already have a few ideas for where Ocelot could go next.

There are some obvious features we’ll probably add over time:

The whole reason Ocelot exists is because we wanted something small.

We’re not trying to build another large operational platform or replicate everything Oban Web already does extremely well.

enough visibility and control for smaller systems

So future features will probably continue following that philosophy.

If something makes Ocelot significantly more complex without solving a real day-to-day problem, we’ll likely avoid adding it.

We’d rather have a small tool that stays useful than a large tool that slowly loses its original purpose.

Ocelot is open source and still very early, but it’s already useful for us internally.

We’d love feedback from other teams using Oban outside of Phoenix.

Do you have projects that use Oban without Phoenix? Would a lightweight dashboard like this be useful for you?

Give it a try and let us know what you think.

Introducing Ocelot: A Lightweight Oban Dashboard Without Phoenix

Part 1: Letting Users Describe Complex Filters


AI is being added to products at a rapid pace. Some features feel genuinely useful. Others feel unpredictable or unnecessary.
In many cases the difference is not the model. It is the interface.
A common pattern today is replacing an existing workflow with a chat box and expecting users to describe everything in natural language. That often removes the structure that made the workflow reliable in the first place.
In practice, the most useful AI features I’ve seen do the opposite. They keep the structure of the system and use AI to translate user intent into something the system already understands.
One place where this works particularly well is filtering.

Many products allow users to filter collections of data.
Examples include:

At first the UI is simple. A few dropdowns or checkboxes are enough.
But as the product grows, filtering often becomes more complex. You start seeing things like:

A UI that once felt simple turns into a small query builder.
Some platforms go even further and introduce their own query languages so users can express complex filters more flexibly.

status:inactive AND total_spend > 500 AND last_order < 90d

These approaches are powerful, but they also introduce friction. Users now have to learn a syntax before they can ask what is often a simple question.
In many cases users already know what they want. The difficulty is translating that intent into the structure required by the interface.

customers who spent more than $500 in the last 3 months and haven't placed an order recently

Representing this through dropdowns, query builders, or a custom filter language can take several steps.

To make this more concrete, I built a small Phoenix LiveView demo that implements this pattern: 

https://github.com/juanazam/example_liveview_ai_u/

The rest of this article walks through the core ideas behind that implementation.

Instead of forcing the user to construct the filter manually, we can let them describe what they want. The idea is simple, use AI to translate natural language into a structured filter that the application already supports. The system still controls the query. The AI only helps interpret the user’s intent.

customers who spent more than $500 in the last 3 months and haven't ordered recently

The AI converts that into structured data such as:

From there the application builds the query using its existing filtering logic.
The important detail is that the model is not generating SQL or database queries. It is only producing structured parameters that the system already understands.

Elixir is a good fit for this pattern because it makes it easy to define clear boundaries between data, validation, and execution.
In the demo app, I use a dedicated response model for the LLM and then map that result into the application’s actual filter struct.
This separation is intentional, the LLM response model defines what the model is allowed to return.
The application filter remains the source of truth for querying.

In this setup, the LLM never interacts directly with the query layer.
It produces a validated 

What Happens When the Model Gets It Wrong?

Large language models are probabilistic systems. Even with a clear prompt and a defined response model, they sometimes return data that does not fit the expected structure.
That is where 

 helps.
It allows you to define a structured response model and retry when the model fails to produce valid output.

A Valid Schema Does Not Guarantee a Correct Interpretation

Even when the response fits the schema perfectly, it may still not reflect what the user actually meant.

customers that spend a lot but haven't bought anything in a while

%CustomerFilter{ min_total_spend: 50000, last_order_before_days: 90 }

This is a valid result. It matches the schema and can be used to build a query. But it may still be wrong.
Maybe in that business context “spend a lot” should mean 2000. Maybe “a while” means six months instead of three.
Schema validation solves the structural problem. It does not solve the semantic one.
There are a few ways to improve this.
One option is to include a confidence field in the response and let the model indicate how certain it is about the interpretation. This can be useful as a UI signal, but it should be treated as a heuristic rather than a guarantee.
Another option is to return multiple possible interpretations instead of forcing a single answer. This makes ambiguity explicit and allows the user to choose the option that best matches their intent.
In practice, both approaches can help, but neither replaces the need for a UI where users can review and adjust the generated filters.


As part of building the demo, I also experimented with a prototype of a reusable filtering layer for Ecto schemas.

https://github.com/juanazam/example_liveview_ai_u/tree/introduce_filter_dsl



The idea is to define filters once and use that definition to:

generate metadata for building filter UIs

support AI-assisted parsing into the same structure

In that model, the filter definition becomes the source of truth, and both the UI and the AI layer become different interfaces over it.


This is still an early prototype, but it feels like it could be worth exploring.

AI works best when it removes friction without removing structure.
Letting users describe what they want while the application remains responsible for how it is executed is a simple but powerful pattern.
Filtering is one example, but the same idea applies anywhere users struggle to express intent through rigid interfaces.

Designing AI Features That Actually Help Users

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 

Mimiquate Blog

Introducing Elixir Observer: A Better Way to Explore Elixir Packages

Introducing Ocelot: A Lightweight Oban Dashboard Without Phoenix

Designing AI Features That Actually Help Users

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