If you've ever worked on a message-based system, at some point you have probably asked the question: How can I connect my asynchronous back-end to the front-end? This webinar is focused on answering this non-trivial question, outlining scenarios and solutions available in our toolbox to easily make the back-end talk to the front-end in a way that is both robust and scalable. The cornerstone of the system we will study in this webinar is SignalR, a library that facilitates adding bi-directional communication between the server and the browser over the WebSocket protocol. We will also see how NServiceBus messaging framework can be used in combination with SignalR. When the basic scenario is up and running, we will venture into making the system scale to many server instances. We will introduce the concept of a backplane that forwards messages to all server instances so that a client connected to one instance can receive messages sent from another one. We will implement the SignalR backplane using Redis, a popular open source in-memory key-value store. Learn how to: * Connect back-end systems to the frontend * Use correlation, and why it's important * Use SignalR with message-based systems * Use SignalR with NServiceBus * Achieve real time notifications in a JavaScript SPA * Provide user feedback in web applications

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.