The only problem was that we didn’t have a realistic payload at hand, so we created one. So we developed the server side first, emitting faked audio alerts on a 30 seconds trigger. We wanted the new functionality to be up and usable on short notice. One type of news should be the “audio alert” that contains a payload of a Base64-encoded wave file. We introduced a web socket channel from the server to each connected client application and sent update “news” through the socket. Because the existing system played the alerts “on site” and all operators suddenly had to work from home (you can probably guess the date range of this story now), the alerts had to follow them to their new main platform, the web application. The audio messages were created by text-to-speech synthesis and contained various warnings and alerts that informed the operators of important incidents happening in their system. But it didn’t cut it for the new requirement that needed audio messages that were played to alert the operators on site to be send through the web and played in the browser application, preferably without noticeable delay. This architecture was sufficient for previous requirements that mostly consisted of data delivery and display on behalf of the user. Our application architecture consisted of a serverside API that could answer a broad range of requests and a client side web application that sends requests to this API. Well, we didn’t exactly rickroll him, we made him rickroll himself. This is a funny story from a while ago when we were tasked to play audio content in a web application and we used the opportunity to rickroll our web frontend developer.
0 Comments
Leave a Reply. |