{"id":434115,"date":"2020-10-23T14:22:52","date_gmt":"2020-10-23T14:22:52","guid":{"rendered":"https:\/\/exotel.com\/uae\/?post_type=blog&p=434115"},"modified":"2023-12-01T11:26:22","modified_gmt":"2023-12-01T11:26:22","slug":"building-a-browser-push-notification-service-using-golang","status":"publish","type":"blog","link":"https:\/\/exotel.com\/uae\/en\/blog\/building-a-browser-push-notification-service-using-golang\/","title":{"rendered":"Building a Browser Push Notification Service \u2014 The Low-Level Design Using the Gorilla\/Websocket Library in Golang"},"content":{"rendered":"\n

(This article originally appeared as a part of a 3 part series here<\/a>.)<\/em><\/p>\n

At Exotel, we have a lot of customers running their support and sales call centers on us. When these agents receive calls, having a real-time notification, with contextual information about the details of the caller, on their browser, saves the customers and the agents a lot of time. It provides for a better customer experience since they do not have to go into the details of any on-going support queries or problems. To make this happen, we have a Push Notification Service that ensures real-time delivery of these notifications.<\/p>\n


\nGenerally, building a reliable push notification service (using the WebSocket protocol) comes with its own set of challenges. This article will talk about the design and implementation details to help overcome these.<\/span><\/p>\n


\nThe Pledge<\/span><\/h2>\n


\nWe will look at the low-level design of the WebSocket server (that handles the push notifications). It leverages the gorilla\/WebSocket<\/a> library. We’ll rely immensely on two essential resources provided by the go language — the go-routines<\/strong> and the go-channels<\/strong>.<\/span><\/p>\n


\nWhat are go-routines and go-channels, you ask?<\/strong> Well, the go language is known to have greatly eased the work of having a multithreaded architecture, both for the developer and also from the resource utilization angle (memory and CPU usage). It has provided two things to help this cause, the go-routines<\/a><\/strong>, which are the methods that can run concurrently with other methods, basically given a fancy name and a makeover. These can be thought of very lightweight threads (~2kb). And the go-channels<\/strong>, which are the communication wires between these go-routines.<\/span><\/p>\n

 <\/p>\n

So essentially, if you want to run something concurrently?<\/strong> Simply create a new go-routine (which is super cheap and easy).<\/span><\/p>\n


\nNow, you want to communicate between these go-routines?<\/strong> [no_highlight background_color=”#E0DFDF” color=”#000000″]Avoid sharing the memory or the variables between these routines, you’ll probably end up frustrated, trying to resolve issues that come with concurrency (race conditions etc.).[\/no_highlight] Instead, pass this variable over something like the communication wire, to the intended go-routines, and this communication wire is go-channels<\/strong> (in-built in go), which passes all the tests of concurrency. <\/span><\/p>\n

This is inline with the language’s philosophy that says “Don’t communicate by sharing the memory, share the memory by communicating”. The channels are like having a queue to communicate between two services, just that this one’s going to reside in your memory, and will help you to communicate between your threads.<\/span><\/p>\n


\nThe Turn<\/span><\/h2>\n


\nOkay, got the terms, now how does the low-level design look like?<\/strong> Well, it would look something like this.<\/span><\/p>\n

 <\/p>\n

\"\"<\/span><\/p>\n

 <\/p>\n

The go-routines and the channels<\/strong> — Here in this architecture, the different boxes denote the different types of worker pools that will run in our server.<\/span><\/p>\n


\nThe worker pools are basically like the different departments in a company. Like how the department employs an employee to get the job done, each worker pool may employ 1 or more workers (go-routines) to get the job done.<\/span><\/p>\n


\nThese company departments need to constantly communicate with each other to achieve a larger company objective. Likewise, the arrows between these workers denote the communication wires laid out for the workers to talk to each other (or the go-channels), which collectively achieve the objective of delivering the notification to our targets. The pool of workers will try to make some requests to some other pool to take care of the next part of the processing, and these requests will be sent over the channels.<\/span><\/p>\n


\nLet us have a look at the different types of worker pools and their jobs.<\/span><\/p>\n


\n1. Source (connection upgrade request) worker pool (HTTP server) –<\/strong> This worker pool processes the incoming connection upgrade requests. It will look at the targetID, the request fields, and the headers, and decide if the request is worthy of a WebSocket upgrade (based on the origin of the request, the authentication credentials, etc.). It will accordingly approve or reject the request.
\n<\/span><\/p>\n

Rejecting the request would simply mean passing back a non OK status as an HTTP response.
\n<\/span><\/p>\n

While approving the request would mean three things
\n<\/span><\/p>\n