I need to make an external API call within a message handler.
Since I’m not accessing the database, I have no need for using the Outbox for synchronizing with the storage.
Would I run into any issues hosting the handler in an endpoint with outbox enabled?
Assuming the API is idempotent, would a Send-Atomic-With-Receive transaction be enough to guarantee that a reply is sent after the API call is made?
What if the API is not idempotent? would it make sense to use some other de-duplication mechanism or implement an in-memory outbox?
How about a IDistributedCache implementation for scenarios where we need a lightweight outbox without the overkill of using SQL?
Hi @DorianGreen
Would I run into any issues hosting the handler in an endpoint with outbox enabled?
Not that I’m aware off. The outbox is on the incoming message that in your case calls the external API.
Assuming the API is idempotent, would a Send-Atomic-With-Receive transaction be enough to guarantee that a reply is sent after the API call is made?
I assume you mean a regular endpoint that doesn’t have the outbox enabled? Because combining outbox with Send-Atomic-With-Receive is not supported.
Based on my experience, integrating with external parties can get messy and those “adapters” usually tend to become their own monsters over time with throttling requirements and more. I would isolate that normally into a dedicated integration or gateway endpoint. Then you can control on the endpoint level the configuration, persistence etc. that is relevant for the integration scenarios with that third-party API.
The benefit is also that it is simpler for the main business logic to have for example a saga that orchestrates the command, the reply and potential compensation actions if required.
This is very similar to what we have in our workshop. See for example the
Fedex Handler that is placed as part of the IT Ops service and the Shipping Saga that lives within the Shipping service.
What if the API is not idempotent? would it make sense to use some other de-duplication mechanism or implement an in-memory outbox?
How about a IDistributedCache implementation for scenarios where we need a lightweight outbox without the overkill of using SQL?
Assuming you’d have this integration endpoint, would you need to scale that one? If not, you could use the non-durable persistence on that endpoint. Later if you need to scale it you can plug in any other persistence that suits your needs on that endpoint.
Regards,
Daniel