Azure Web PubSub is a way to open up a websocket between the user client and a resource server to continuously pass data through it. The client (or even multiple clients) does not need to repeatedly send HTTP requests to the server to receive data or repeatedly poll the server for status updates.
The following is a short example that shows a client web page that opens up a websocket to a known Azure Web PubSub service instance, whereby images are served back to the client continuously in response to a Timer triggered Function.
💡
The following is a heavy modification of the common 'Azure Web PubSub Notification' sample, and is run locally for clarity.
Some prerequisites:
A free tier Azure Web PubSub Service in Azure
Visual Studio plus a set of test jpg Images under 1MB each, added to the root of the project and all configured to Copy to the Output Directory upon Build: In Visual Studio, this can be done from setting the image's Advanced Setting for Copy to Output Directory to Copy if newer;
To be able to interact with our websocket, we can create an HTML page called index.html that will render the data we are looking for, and this HTML file too should have a Build Action of 'Copy if newer' in Visual studio:
To be able to see this index.html file, we can create an HTTP triggered Function that will read the file from the localhost server like so:
Next, add the following HTTP triggered Function (called negotiate) as below. This function gets called from the index.html page when that html file renders and this attempts to connect to the Web PubSub instance:
And for connecting to the Web PubSub instance in Azure, go to the local.setting.json file, add the key "WebPubSubConnectionString" and the value will be the connection string for the Azure Web PubSub instance (connection string is found in the Web PubSub instance's 'Keys' detail menu in Azure).
💡
Wait but how??.. The WebPubSubConnection Input binding will look for a "WebPubSubConnectionString" configuration key and its value for a connection string
To providing images continuously over the websocket back to the client when the index.html loads, we can use a Timer Trigger Function (called FetchImage) that will execute every 10 or 15 seconds for example. Here, an image is picked out from the image set (that live on the localhost server) and written to the websocket as a Stream:
Back on the index.html page, these Streams are received and are converted to base64 strings which are used as the image sources, which the client browser interprets as images that we can see!
Example Run!!
To run the output we need to go to the HTTP function that renders the index.html. After starting a debug session in a local environment, this will be at http://locahost:{YOUR_PORT_NUMBER}/api/index
Here is a video of what would happen once running (All test source image Credits: Jimmy Chan on Pexels):
Conclusions and final thoughts
I think the Azure Web PubService is extremely useful where there might be a need to reduce complexity and ease burden on the client-side by reducing the need to use AJAX calls for example. In my example I use it for a novel use case of generating randomly ordered photo grid where the image source url is virtually hidden from the client with the use of base64 strings (Privacy bonus for the serverless service perhaps!! 🤔).
While the above may be true, I should point out that transmitting heavier data such as images like this is not really the intended usage scenario as the message payload size is rather small on the Free Tier (appears to be 1MB from what I've been able to test), and the data quota per day on the Free Tier is 40 000Kb. Azure Web PubSub is more suited for passing much smaller messages and status updates in real time to multiple clients, automatically. Always fun testing though 😎
And finally, for production, we should not use Anonymously available Azure Functions as discussed in this exploratory example, use Function level access or place Functions behind APIM instances!!