Connect front end to back end using SignalR and Messaging
3 likes2,115 views
The document discusses the use of SignalR for bi-directional communication between front-end and back-end systems, highlighting the differences between synchronous and asynchronous styles. It emphasizes the importance of managing correlation IDs for tracking requests and responses, as well as the challenges related to scaling out applications and maintaining connectivity. Various technical scenarios and solutions, including the use of NServiceBus and RabbitMQ, are illustrated to support efficient communication and error handling.
![[WIP] Demo #2 - Recap](https://image.slidesharecdn.com/connectfront-endtoback-end-160501073259/85/Connect-front-end-to-back-end-using-SignalR-and-Messaging-17-320.jpg)
Connect front end to back end using SignalR and Messaging
- 1. http://particular.net Connect front-end to back-end using SignalR and Messaging Mauro Servienti & Sean Feldman
- 2. Bi-directional communication It can be hard…
- 3. Synchronous / RPC style • Client utilizes RPC • Client is blocked by server • Easy to: • Handle the conversation • Handle server errors • Hard to scale out • Only option is a load balancer client server synchronous execution request response
- 4. Asynchronous / RPC style • Client still utilizes RPC • Client is blocked waiting for server • Easy to: • Handle the conversation • Handle server errors • Less hard to scale out • Better server resources management • Load balancer still needed client server asynchronous execution request response async await
- 5. Truly asynchronous • Client issues a request • Client receives an immediate ACK • Client is not blocked • Server starts background work • Easy to scale out • Offload work to multiple machines • Harder to handle: • the conversation • background execution errors client server request status notification start report ACK background execution different process and/or different machine
- 7. Ping / Pong: sample scenario SPA client web server Ping request Pong notification Request received Back-end server background execution Handle ping Pong response
- 8. AzureEmulator Back-end server Ping / Pong: technicalities • Client utilizes SignalR: • To send requests • To subscribe to events • Server utilizes: • NServiceBus • RabbitMQ • Azure “full” emulator • Dev machine load balancer SPA client web server Ping request Pong notification Request received RabbitMQbroker Ping Message Pong reply SignalR SignalR background execution
- 9. Demo #1
- 10. Demo #1 - Recap
- 11. Correlation
- 12. What correlation is • Clients need to correlate back server replies/notifications • Correlation ID is used to leave breadcrumbs to find your way back • as in the “Ariadne’s thread” • Correlation ID must be attached to each message • SignalR or NServiceBus • Correlation ID should be generated by the originating client
- 13. Ping / Pong: Correlation ID SPA client web server Ping + Correlation ID Notification + Correlation ID ACK Back-end server background execution Pong + Correlation ID Message + Correlation ID
- 14. Server-side “Correlation ID” generation • Client issues new request • Server generates Correlation ID • Server sends back ACK • ACK is lost (e.g. connectivity issues) • Client might be left in an unknown state
- 15. Client-side “Correlation ID” generation • Client issues new request + Correlation ID • Server sends back ACK + Correlation ID • ACK is lost (e.g. connectivity issues) • Client can resubmit the same request with the same Correlation ID • Server can de-duplicate based on the Correlation ID
- 16. Demo #2
- 17. [WIP] Demo #2 - Recap
- 18. Scale out
- 19. Scale out: what can go wrong? • The client might be connected to the wrong web server instance • Not the one receiving the “pong” reply • The web server instance might be recycled • Causing the client to connect to another instance • The client might lose connection to the web server • Causing the client to connect to another server
- 20. Ping / Pong: Scale out scenario web server #1 Ping request Pong notification Request received Back-end #1 Ping Pong web server #2 web server #n Loadbalancer Web farm RabbitMQbroker Back-end #n Pong Competing consumers Competing consumers SPA client SPA client
- 21. Backplanes To scale it out much better
- 22. Backplane & scale out scenario SPA client web server #1 Ping request Pong notification ACK Back-end #1 Ping Pong web server #2 web server #n Loadbalancer Web farm RabbitMQbroker Back-end #n Pong Competing consumers Competing consumers Redis Backplane Pong received SPA client
- 23. Demo #3
- 24. Demo #3 - Recap
- 25. Q&A Thank you.