Bridging Elixir and Python with Oban · Oban Pro ← All Articles Bridging Elixir and Python with Oban February 3, 2026 elixir python tutorial What choices lay before you when your Elixir app needs functionality that only exists, or is more mature, in Python? There are machine learning models, PDF rendering libraries, and audio/video editing tools without an Elixir equivalent (yet). You could piece together some HTTP calls, or bring in a message queue…but there’s a simpler path through Oban. Whether you’re enabling disparate teams to collaborate, gradually migrating from one language to another, or leveraging packages that are lacking in one ecosystem, having a mechanism to transparently exchange durable jobs between Elixir and Python opens up new possibilities. On that tip, let’s build a small example to demonstrate how trivial bridging can be. We’ll call it “Badge Forge”. Forging Badges “Badge Forge,” like ” Fire Saga ” before it, is a pair of nouns that barely describes what our demo app does. But, it’s balanced and why hold back on the whimsy? More concretely, we’re building a micro app that prints conference badges. The actual PDF generation happens through WeasyPrint , a Python library that turns HTML and CSS into print-ready documents. It’s mature and easy to use. For the purpose of this demo, we’ll pretend that running ChromaticPDF is unpalatable and Typst isn’t available. There’s no web framework involved, just command-line output and job processing. Don’t fret, we’ll bring in some visualization later. Sharing a Common Database Some say you’re cra-zay for sharing a database between applications. We say you’re already willing to share a message queue, and now the database is your task broker, so why not? It’s happening. Oban for Python was designed for interop with Elixir from the beginning. Both libraries read and write to the same oban_jobs table, with job args stored as JSON, so they’re fully language-agnostic. When an Elixir app enqueues a job destined for a Python worker (or vice versa), it simply writes a row. The receiving side picks it up based on the queue name, processes it, and updates the status. That’s the whole mechanism: Each side maintains its own cluster leadership, so an Elixir node and a Python process won’t compete for leader responsibilities. They coordinate through the jobs table, but take care of business independently. Both sides can also exchange PubSub notifications through Postgres for real-time coordination. The importance of that tidbit will become clear soon enough. Printing in Action This is more of a demonstration than a tutorial. We don’t expect you to build along, but we hope you’ll see how little code it takes to form a bridge. With a wee config in place and both apps pointing at the same database, we can start generating badges. Enqueueing Jobs Generation starts on the Elixir side. This function enqueues a batch of (fake) jobs destined for the Python worker: def enqueue_batch ( count \\ 100 ) do generate

Source: Hacker News | Original Link