Reactive Interaction Gateway (RIG) is an Apache-2.0 licensed, Elixir-built gateway that makes communication between a frontend and stateless microservice backends reactive and event-driven, and it is aimed at teams that need live data in the browser without building polling loops or SDK plumbing into their applications.

What it is

RIG is the glue between a client frontend and a backend. It picks up backend events and forwards them to clients based on subscriptions, which makes frontend applications reactive and eliminates the need for polling. Event pickup works asynchronously through Kafka, NATS, or Amazon Kinesis, or synchronously if the team does not want to operate a message broker. In the other direction, RIG forwards client requests to backend services: synchronously as a reverse proxy, asynchronously as fire-and-forget by transforming an HTTP request into a message for Kafka, NATS, or Kinesis, and in two pseudo-synchronous variants that keep the client connection open while the backend response arrives through the broker.

The concrete problem it solves is the missing push channel between stateless microservices and a browser. Stateless HTTP services have no natural way to tell a client that state changed, so teams bolt on polling endpoints or write per-service WebSocket handling. RIG replaces that polling and that per-service push plumbing with a single gateway that speaks open standards. It lives in the Elixir and OTP ecosystem and integrates with Kafka, NATS, Amazon Kinesis, Server-Sent Events, and the CloudEvents schema. Crucially, it does not leak into the application: no libraries or SDKs are required, which the project frames as low-cost, low-risk adoption and easy replacement.

Key capabilities

• Picks up backend events and forwards them to subscribed clients asynchronously over Kafka, NATS, or Amazon Kinesis, removing the need for polling.
• Forwards backend events synchronously when no message broker such as Kafka is in place.
• Acts as a reverse proxy: forwards a client request to a backend HTTP endpoint, waits for the response, and returns it to the client.
• Fire-and-forget mode: transforms an incoming HTTP request into a message and forwards it to the backend asynchronously over Kafka, NATS, or Kinesis.
• Pseudo-synchronous request mode with asynchronous response: forwards the request synchronously over HTTP, then listens on Kafka or NATS for the backend response and pushes it to the still-open HTTP connection.
• Pseudo-synchronous request mode where both the request and the response travel asynchronously through Kafka or NATS while the frontend connection stays open.
• Ships as a published Docker image, accenture/reactive-interaction-gateway, and supports event subscriptions, Server-Sent Events delivery, and CloudEvents-shaped payloads.

Who uses it and how

• Frontend teams that need live data — dashboards, activity feeds, notifications — and want to delete their polling code instead of tuning poll intervals.
• Organizations running stateless microservices that already produce events into Kafka, NATS, or Kinesis and need a delivery path to browser clients.
• Teams that want to avoid a message broker entirely and use RIG's synchronous and pseudo-synchronous modes as the transport instead.
• Platform teams deploying RIG on Kubernetes, where dedicated deployment instructions are published in the repository's deployment directory.
• Teams that refuse vendor lock-in at the application layer, since RIG requires no libraries or SDKs inside the services it fronts.

Getting started

The getting-started tutorial provides a simple walkthrough using Docker with the accenture/reactive-interaction-gateway image. For Kubernetes, the repository publishes dedicated deployment instructions under its deployment directory.

How it compares

This registry entry lists no paid products that RIG replaces, and the facts name no directly comparable gateway projects, so RIG stands alone here. What the facts do establish is a contrast in kind: adoption requires no SDK or library inside the application, and the gateway is built on open standards, which the project presents as making it easy to integrate and easy to replace.

When to use it — and when not to

A self-hoster must run the Elixir service, likely via the Docker image, and decide on a transport: picking asynchronous event forwarding means operating Kafka, NATS, or Amazon Kinesis alongside RIG, while the synchronous modes trade that operational burden for a broker-free but more limited design. Teams that want a single-vendor managed API gateway with a support contract should not pick it, because RIG is a community Apache-2.0 project distributed through GitHub and Docker Hub with issues handled in public. The honest caveats are a README that summarizes capabilities and defers to an external documentation site for detail, and 74 open issues against 602 stars and 67 forks, which suggests an active but not heavily resourced project.