Bridge sync and async
Cross the boundary between HTTP and your brokers.
An HTTP client publishes to Kafka, AMQP or MQTT without a broker client; a browser consumes a stream over SSE or WebSocket; a partner receives its tenant's events through a signed webhook. All go through the same controls.
The path
- DeclareChannels in an AsyncAPI contract, next to the OpenAPI contract
- PublishOver HTTP or through an MCP tool, CloudEvents envelope
- ConsumeOver SSE, WebSocket or a signed, replayable webhook
- ControlIdentity, tenant and quotas, as for a REST call
An event's tenant comes from the verified identity: a subscriber never reads another tenant's events.
Configuration
No complete example for this domain in release v1.6.3 yet: one will come with an upcoming release.
Features
What is delivered in the published release v1.6.3, and what is coming; a feature is never shown as delivered before its release.
| Feature | Status |
|---|---|
| AsyncAPI as the source of the asynchronous plane | Delivered · v1.5.0 |
| Kafka publishing under contract, CloudEvents envelope | Delivered · v1.5.0 |
| Mediation of the synchronous to asynchronous boundary | Delivered · v1.5.0 |
| AMQP(S) and MQTT | Delivered · v1.5.0 |
| Signed, replayable outgoing webhooks | Delivered · v1.5.0 |
| Native Kafka proxy: Kafka clients on the gateway, virtual clusters and topics per tenant | Delivered · v1.6.1 |
Going further
Let's talk about your gateway
Flexwiz is a young company: you talk directly with the person who founds it. Tell us what you want to run through Flexway. We talk about your infrastructure and your digital sovereignty requirements.
Online booking is coming soon; until then, an e-mail is enough.