Case study
React/Node - Realtime horse racing TV broadcast studio software development
Problem: They had a existing broadcast studio system built in some of technology (I think it was COBAL) which was outdated and also could not be modified anymore because the system was too complicated
Overview
Client: The biggest horse racing broadcasting tv studio in Australia.
Problem: They had a existing broadcast studio system built in some of technology (I think it was COBAL) which was outdated and also could not be modified anymore because the system was too complicated and the original developer had left. This existing system was not modifiable and was not providing the capabilty and flexibility that was needed for the current and future needs. It needed a rewrite.
Solution: Build a new version of the horse racing broadcast studio software in React and Node (hence modern technology) which will be convenient for the studio users, offer much more features in a more convinient way. It would control the outputs to the VIZ Studio which mixes of the video of the races with the race information from the studio software.
The project as the Lead Frontend React developer & Node developer
I was commissioned as the solo Lead React Developer for this Greenfield project. I was part of a 3 member team. Myself, a Node developer and the SME who was a .NET developer who knew the existing system well.
As I was the most expeienced lead JS/React/Node developer, I provided technical guidance, solutions, lead the direction of the React application, code standards, code review did the actual coding. I wrote majority of the react code and wrote a lot of the Node.js, Further, I ensured good Architecture, ensuring scalable solution and Mentoring the team in regard to agile practices. It needed a very scalable solution as there is a massive amount of data (race data as well as betting odds data) that constantly updates and needs to flow from the data source to our BFF (our backend) and then to the frontend.
It needed to be real time also as the races are broadcast needs to presend live odds and live race informations in the TV broadcasts.
The Architecture and the system’s requirements
Being a real time application, we implemented websockets and pub / sub messaging between the frontend and the backend.
When the React frontend application initially loaded, it will first open the websocket for communication. It will send a message to get the list of races and will subscribe to race list updates channel. When a particular race is being broadcast, it will subscribe to a rase specific channel to get detailed real time race update messages for that race. The Frontend state was maintained in Redux.
The UI needed to show the live information too. So it will automattically move, auto scroll, change details and updated with the different ‘updates’ from the backend. The studio user needed to interact with the UI as they made their selections on the broastcast based on this information presented to them. e.g. show the odds, show which race information etc.
The backend when ran, will setup channels which can be subscribed to for update ‘streaming’ information. The backend will listen for ‘command’ messages and respond accordingly. It handed the requests by mapping the frontend command messages to a graphql query / mutation. The backend also ran the graphql resolver. In essence, it talked to itself using graphql.
This meant the frontend did not have to know about the backend graphql schema and greatly simplified the frontend code. The frontend simply sent simple messages with very simple payloads which was appropriate for this project. The frontend using pub/sub with the backend meant, the backend can provide the frontend with only the relevant information. e.g. the frontend will subscribe to specific races’ live data (the x number of upcoming races) and stop subscribing to the previous races so that it does not get bombarded with all race update and data, keeping the frontend fast and efficient.
The Node backend has to handle the frontend but also has to handle its own backend where the real data came from. It was a BFF.
The Node backend It also had to control the broadcast VIZ, to know the state of the VIZ. Eventually xstate was used to manage the VIZ state so we could more systematically control the state using a state machine. For the VIZ Studio, only certain transitions of scenes of the broadcast are possible hence this can be mapped into the state machine.
Technical Skills
React, Redux, ES6, Styled components, Jest, CSS, DOM, Web sockets, mqtt, rabbitMQ Node.js scalable microservices, GraphQL, redis, node-cache (mongo) Agile, sprint, scrum
Summary
Overall, it was fun and successful project. Technically, it was ful too using web sockets and being a real time application. We were able to get things done very quickly being very agile with a tight 3 member team.
The frontend work was great. The UI/UX was evolved iteratively and the solution was very nice. It was fancy and moving and updating all the time and fast and responsive. The backend work was interesting using xstate for state and action management, graphQL, MQTT pub/sub technologies.
Leading the frontend and working as full stack and providing mentoring and also providing well thought out solutions was a greatly satifying and rewarding.