Replies: 1 comment 1 reply
-
This sounds great.. !! @lbroudoux Here, about transferring the context of a request/response to a async request (like a webhook or directly push into the kafka topic). What my idea is that like we have "dispatching rules" right ! We can have an option like, "trigger endpoint" or something like this and there can be rules, based on which there can be templates inside the "async api endpoint" or KAFKA event. Because I think both facilities should be there, the ability to push the message inside a kafka topic or send a webhook. Doing this, I think it would really streamline the current implementation |
Beta Was this translation helpful? Give feedback.
-
Hey Microcks users!
I’d like to introduce here an idea I had in mind for a long time as I’m wondering if there’s some interest and if the time has come to implement it. As stated by the title, this is all about triggers 😉
The rough idea is the following: it's a very common pattern to have a synchronous interaction (ie. invocation of Rest/Soap/Graph/Grpc API operation) triggering the publication of an asynchronous event on a channel (and thus an AsyncAPI subscribe operation). So why not be able to define this triggering from the mocking step in API lifecycle?
I see two different areas to address and that could be easy to set up in Microcks. First one is about how to define this link using API specs and in Microcks ; second one is about how to propagate context from sync request to async message to get coherent content. Here are there after some thoughts on how we could proceed.
Defining trigger link
This can be done in different ways. The first one I see is defining a new
x-microcks
OpenAPI extension. On the synchronous side (eg. the OpenAPI spec) we could define a new notation like:OR we can do it on the asynchronous side (eg. the AsyncAPI spec), with a new extension like this one:
Of course we can also imagine having this added to our own APIMetadata spec if you don't like scattering your API spec with extensions. 😉
Propagating context
How to reuse content from the incoming request into our triggered event messages ? Simply by using the templating feature already present in microcks and using the specific
request
orresponse
attributes. Asrequest
orresponse
may only make sense in the case of a triggered publication, it may be used as a filter among the examples attached to an operation. Is your example message using the{{request\.(.*)}}
pattern? If yes it will be used when triggering, if no it will only be used in regular scheduled mock messages.You can also imagine combining this with some headers magic for helping correlation identifier propagation …
We need you!
These are just early thoughts on what we could achieve regarding mocking in a hybrid (sync / async ) API world! Please feel free to react and engage in the discussion, sharing your view on this topic! Feedback is a gift!
Beta Was this translation helpful? Give feedback.
All reactions