> It's less obvious to me how your proposal lines up with things that are less so.
Usually you have a sync wrapper around async work, maybe poll based.
As an example, I believe that Amazon's "place in cart" is completely async with queues in the background. But, of course, you may want to synchronously wait on the client side for that event to propagate around.
You get all of the benefits in your backend services - retry logic is encapsulated, failures won't cascade, scaling is trivial, etc. The client is tied to service state, but so be it.
You'll want to ensure idempotency, certainly. Actually, yeah, that belongs in the article too. Idempotent services are so much easier to reason about.
So, assuming an idempotent API, the client would "send", then poll "check", and call "send" again upon a timeout. Or, more likely, a simple backend service handles that for you, providing a sync API.
Going from Sync to Async usually means splitting up your states explicitly.
For example:
Given two communication types:
Sync (<->)
Async (->)
We might have a sync diagram like this:
A <-> B
A calls B, and B 'calls back' into A (via a response).
The async diagram would look like one of these two diagrams:
A -> B -> A
or:
A -> B -> C
Whatever code in A happens after what the sync call would have been gets split out into its own handler.
If your system is extremely simple this may not be worth it. But you could say that about anything in the article, really.
Usually you have a sync wrapper around async work, maybe poll based.
As an example, I believe that Amazon's "place in cart" is completely async with queues in the background. But, of course, you may want to synchronously wait on the client side for that event to propagate around.
You get all of the benefits in your backend services - retry logic is encapsulated, failures won't cascade, scaling is trivial, etc. The client is tied to service state, but so be it.
You'll want to ensure idempotency, certainly. Actually, yeah, that belongs in the article too. Idempotent services are so much easier to reason about.
So, assuming an idempotent API, the client would "send", then poll "check", and call "send" again upon a timeout. Or, more likely, a simple backend service handles that for you, providing a sync API.
Going from Sync to Async usually means splitting up your states explicitly.
For example: Given two communication types: Sync (<->) Async (->)
We might have a sync diagram like this:
A <-> B
A calls B, and B 'calls back' into A (via a response).
The async diagram would look like one of these two diagrams:
A -> B -> A
or:
A -> B -> C
Whatever code in A happens after what the sync call would have been gets split out into its own handler.
If your system is extremely simple this may not be worth it. But you could say that about anything in the article, really.