Modernizing Real-Time Infrastructure and Improving Observability for Supabase

Building the proof of concept

We started with a PoC. The client trusted us to make the right technical calls and check in with updates. That trust set the tone for our whole collaboration.

One of the first things that became clear was that Phoenix lacks proper type definitions. The library used JSDoc comments – and some of those comments referenced types that didn't exist, or described functions vaguely. We worked through them carefully, using AI to write correct type definitions and keeping the changes as minimal as possible so that integrating future Phoenix.js updates would be straightforward.

After roughly one and a half months, the PoC – covering all key functionalities – confirmed that the migration was viable, and the client asked us to proceed with the implementation, focusing on improving code quality, fixing types, updating unit tests, and ensuring the API looks the same.

Working on the full implementation

The central benefit of moving to Phoenix.js was a shift in responsibility: the WebSocket connection layer now belongs to the Phoenix.js project. This means that instead of owning a diverging fork, Realtime.js became a wrapper: cleaner, lighter, and easier to keep current going forward.

The main constraint we worked within was that this change couldn't be visible to developers using the SDK. The API had to look and behave the same. To achieve that, we built an abstraction layer over Phoenix.js, aligning function names and call signatures where possible so that existing code would continue to work without modification.

During this process, we discovered a subscription issue. It was an edge case where trying to subscribe to a channel more than once would be silently blocked, due to how Phoenix.js manages channel state. We identified the cause, advised the client on the right fix, and added a helper function that correctly handles callback transfer and channel recreation. We also made a handful of smaller contributions upstream to Phoenix.js itself during the course of the work.

Finding the right approach to testing without direct platform access

Testing a client tool when you can't run the full platform behind it requires a different approach. Since Supabase is open source and we were building a library, the only real way to verify our work was to build applications that actually use it.

The client gave us the freedom to treat this like a hackathon: we were allowed to build something real, see what works, and learn from that.

So, we built a shared terminal demo and an interactive Realtime explorer: a browser app where you can configure connections, set up channel bindings, and observe messages flowing in real time.

These apps were the foundation for a mini test suite, with automated tests running against the actual library in the browser, giving the Supabase team a practical way to verify Realtime behavior.

React Native integration

The client wanted to make Realtime work reliably in React Native. We knew there were cases when a mobile app goes into the background and the WebSocket connection drops, and restoring it cleanly when the app comes back to the foreground wasn’t handled well in the previous implementation.

That’s why we decided to extend the test playground to run as an Expo mobile application, reproduced and confirmed the reconnection behavior, and built a set of React Native hooks that tie Realtime channel connections to the mobile app lifecycle. With these hooks, connections are managed automatically depending on whether the app is active or backgrounded, closing a gap that had caused problems for React Native developers using Supabase Realtime.

We also published an open-source scaffold repository demonstrating how to approach Realtime integration in React Native, which can serve as a starting point or reference for the community.

Working on the ingestion pipeline's rule evaluation logic

Logflare's ingestion API is where incoming log events are received and routed. Each event is evaluated against a set of user-configured rules to determine where it goes. Those rules can match on values and apply various conditions. With the original implementation, every rule for a given source was checked against every event, one by one.

We rebuilt this as a tree-based data structure: rather than walking the entire rule list for every event, the system now traverses the tree and prunes branches that can't apply early in the process. Only the rules that are actually relevant to a given event get evaluated. This brings evaluation closer to logarithmic complexity, meaning the system checks far fewer rules per event compared to a sequential scan.

Working on Adapters to enable data export from Logflare

We implemented a set of adapters that allow exporting logs from Logflare to external observability services. This included integrations with Axiom and Last9, as well as an adapter for OTLP (OpenTelemetry Protocol), which serves as a universal standard for telemetry data exchange.

Delivering this required refactoring parts of the existing adapter system to make it more consistent and extensible, ensuring new destinations could be added without increasing system complexity. These changes also laid the groundwork for the Supabase’s new Log Drains destinations, which route logs from the Supabase stack to third-party services.

More recently, we extended the adapters with connection testing capabilities, allowing users to validate external integrations before enabling log streaming.