Hans Karlsen (talk | contribs) No edit summary |
Hans Karlsen (talk | contribs) No edit summary |
||
| Line 1: | Line 1: | ||
If you build a whole (micro) service universe you will soon notice a need for events triggered from one system | If you build a whole (micro) service universe you will soon notice a need for events triggered from one system sent to another. | ||
This can - and is - often handled as Rest-api's on two systems that call each other. While this strategy may get the job done you have an issue with the two systems must know about | This can - and is - often handled as Rest-api's on two systems that call each other. While this strategy may get the job done you have an issue with the two systems must know about each other - and this quickly turns into a spaghetti tangled web of services that cannot really change without breaking something. | ||
A much better approach is to have the more generic of the two systems expose a generic callback - an event. | A much better approach is to have the more generic of the two systems expose a generic callback - an event. | ||
Such events best implemented by an open socket that can be used by the generic system to signal events - that in turn may cause action in the caller. | Such events are best implemented by an open socket that can be used by the generic system to signal events even if it knows nothing about the listener - that in turn may cause action in the caller. | ||
In .net SignalR is implementing this infrastructure. | In .net SignalR is implementing this infrastructure. | ||
Revision as of 16:35, 15 November 2020
If you build a whole (micro) service universe you will soon notice a need for events triggered from one system sent to another.
This can - and is - often handled as Rest-api's on two systems that call each other. While this strategy may get the job done you have an issue with the two systems must know about each other - and this quickly turns into a spaghetti tangled web of services that cannot really change without breaking something.
A much better approach is to have the more generic of the two systems expose a generic callback - an event.
Such events are best implemented by an open socket that can be used by the generic system to signal events even if it knows nothing about the listener - that in turn may cause action in the caller.
In .net SignalR is implementing this infrastructure.
In MDrivenServer we use SignalR to enable internet signaling and event sending to subscribers
realtimesubscribetoevent
realtimetriggerevent