Updating UI app using background process/service.
Let’s start.
Pattern 1 ( request to response )
Pattern 2 ( client to server and server to client)
Pattern 3( Pattern 2 with worker/background service)
Pattern 1 is classic web pattern where client initialized conversation with server and server gives back the information. Pattern 2 is modern web pattern where nature of application is such that server needs to talk to client without client initiating the conversation. When we see pattern 3 , we feel why this pattern exist and what is that background service at first place? Let’s break this pattern.
Background service or worker service is a program that can perform CPU intensive task or complex task behind the scene. Now you will be like Sumit we can do this without background service attached to server but my response is simple this thing will help us scale. Take any real time apps like zomato or swiggy or any food delivery app where there is a feature of real time status which conveys which step your order is at. eg is it out for delivery or is your order getting prepared etc. You can find this pattern in microservice powered e-commerce website, you buy a product and rest processing of this product is done by background service. You won’t keep a server busy all the time for processing orders. Server will just put in it queue or database and using publisher/subscriber pattern on receiving new order, background service will receive event and process that. I hope I have convinced you now why to use background service.
But the biggest question will arise in careful reader’s mind will be how can we inform progress of background service to client(webapp client). Before exploring that question let’s understand another scenario background service with publisher/subscriber pattern is very practical with reporting systems eg. orders come you want to send those to analytical system or mailing system or reporting system etc. In such scenarios, progress of background service is not required and this pattern (background service one) becomes natural choice. Okay!!! let’s understand our biggest question and main topic of this post.
I developed a simple application which updates random numbers in real time which is produced by some other system. This application can help us understand how background process can update UI app. Below is the architecture.
Producer is producing random numbers and inserting it into kafka partition queue on which consumer has subscribed. When new random number is present in queue, consumer will pick that up and server(signalR one) will update all connected clients to it saying “ Hey this is new update by background process ☺ .display it to end user” . Sumit!!! wait how did server and consumer communicated? SignalR is hosted in background service. I know there is specific to .NET world but similar thing can be visualized in other technology stack as well( All you have to do is let background service communicate with your websocket server and websocket server will pass that info to all connected clients ☺).
Let’s walk through food delivery app example using this pattern. You ordered something. Order will be queued or sent to some bus using server, using publisher/subscriber pattern background service being subscriber will pick that order and keep sending real time status of that order to server which will broadcast it to clients connected to it.
I hope you understood now why and how to update UI using background service.
Code : https://github.com/Sumeetgaara/Background-service-updating-UI?files=1
Demo Video:
https://youtu.be/as1JEbTLL10
Careful reader might still have a question if we distribute clients over multiple servers(for scaling purpose) how will server know which client to update with the progress of background service? hahahahahahh! another post coming up. ☺
Happy coding.
