Case Study: Radio Program Analysis App for Swiss Federal Agency

Before you continue, I have to warn you: this is not another Jamstack case study of ours. But don’t be put off by that.

Hi Kai….thx for doing this. Now, what is your role/what does your company do?

The LINK Institute is the Swiss market leader in the market and social research. My department, IT Development, supports our researchers with software whenever needed. As head of IT Development, I make the software planning and design decisions and write the code together with my three colleagues.

What is the Radio Program Analysis app project about?

One of our clients needed an easy and elegant solution that would help in running and maintaining a detailed analysis of the radio program in Switzerland. The project had two parts, recording and analyzing. Recording meant they needed an option to follow and record the radio program of five public stations at the randomly selected recording dates during the course of a year.

The analyzing process is done by listening to the recording, adhering to the information, and putting them into predefined categories (News, Weather, Music, etc.). Each category has its unique subcategories with complex dependency rules between them.

The LINK researcher in charge of the project asked the IT Department to build a software that would support the analyzing process by providing a user interface that replays the recording and displays the different (sub-) categories, and manages their dependencies to each other.

Did you build the app from scratch?

Nope. This study has been conducted in the past by a different provider who relied on a desktop application. Nothing wrong with that, but we were confident that a web application is a far better approach that would solve many issues they experienced.

Besides, a solution based on a browser-independent web application is always less troubling for our IT Support because they don’t get bothered about release rollouts.

We were certain that we needed a user interface as lean as possible for the complex task of radio program analysis. And we needed an easy solution to handle user permissions.

Bejamas to the rescue. What was our part in this project?

Well, the decision for a web application was made very early. At the same time, we knew we wouldn’t have enough resources available in our internal development team to implement front and backend at the same time.

Our development team has strong C# and SQL knowledge, and you guys have great knowledge on the web front end design and implementation, especially React-based ones, so our decision was clear.

We would use SQL Server as data storage and React as front-end technology. The communication between the frontend and backend would be done by a REST service implemented in C#.

I think you, Gracjan, can explain it a bit more.

Right. For the most part, this is a React app built on Umi.js, an extensible enterprise-level front-end application framework. We also used the global state solution dva.js since it is a component of Umi.js. For the visual layer, we used Ant Design because this React UI framework already has a lot of ready to use components, so we didn’t have to write so many styles.

And the challenges you guys had?

The biggest challenge was a coding section in the radio view. In this view, we had to connect the Media player with the Table of logs. To better understand this process, let me describe the main workflow.

Each media file (usually 5-hour records) has a list of logs. The log is the media record fragment with some data about startTime, endTime, and values for each form field. Basically, when a media file is playing, when we hit a proper log, we should automatically mark this log in the table and fill all fields in the form.

Under the hood, this is a huge React component with a lot of children components. As you can imagine, there are many props, Redux actions, and internal states. So, the main problem was to save performance in this view because all these small components were re-rendered many times.

Another problem was the idea of keeping the form validations rules on the backend side. Once we handled these validation rules, we hit a big problem with re-renders on each form field - refreshing values process. Because this validation idea was brought up after we built the components' structure, we had to do a lot of refactors of code structure and met other rendering / refreshing problems.

And yes - we could have done this better. I think that there are many places to improve/refactor the entire code structure to get fewer amounts of re-renders.

Enough talk from me. Results?

Educating the analysts on the app started 6 months after development kicked-off. Today, 20 analysts are working simultaneously on 350 hours of radio broadcast.