Relier synchrone et asynchrone
Franchir la frontière entre HTTP et vos courtiers.
Un client HTTP publie sur Kafka, AMQP ou MQTT sans embarquer de client de courtier ; un navigateur consomme un flux en SSE ou en WebSocket ; un partenaire reçoit les évènements de son tenant par un webhook signé. Tous passent par les mêmes contrôles.
Le trajet
- DéclarerLes canaux dans un contrat AsyncAPI, à côté du contrat OpenAPI
- PublierEn HTTP ou par un outil MCP, enveloppe CloudEvents
- ConsommerEn SSE, en WebSocket ou par webhook signé et rejouable
- ContrôlerIdentité, tenant et quotas, comme pour un appel REST
Le tenant d'un évènement vient de l'identité vérifiée : un abonné ne lit jamais les évènements d'un autre tenant.
Configuration
Pas encore d'exemple complet pour ce domaine dans la version v1.6.3 : il arrivera avec une prochaine version.
Fonctionnalités
Ce qui est livré dans la version publiée v1.6.3, et ce qui vient ; une fonctionnalité n'est jamais présentée comme livrée avant sa version.
| Fonctionnalité | Statut |
|---|---|
| AsyncAPI comme source du plan asynchrone | Livré · v1.5.0 |
| Publication Kafka sous contrat, enveloppe CloudEvents | Livré · v1.5.0 |
| Médiation de la frontière synchrone vers asynchrone | Livré · v1.5.0 |
| AMQP(S) et MQTT | Livré · v1.5.0 |
| Webhooks sortants signés et rejouables | Livré · v1.5.0 |
| Proxy Kafka natif : clients Kafka branchés sur la passerelle, clusters et sujets virtuels par tenant | Livré · v1.6.1 |
Pour aller plus loin
Parlons de votre passerelle
Flexwiz est une jeune entreprise : vous parlez directement avec la personne qui la fonde. Dites-nous ce que vous voulez faire passer par Flexway. Nous parlons de votre infrastructure et de vos exigences de souveraineté numérique.
La prise de rendez-vous en ligne arrive bientôt ; d'ici là, un e-mail suffit.