One-on-One Video Conferencing System | Case Study

These days, the world uses new technologies while communicating online, which has become a new normal. At MLSDev, we strive to evolve and gain new expertise in line with the market demands.

Aside from this fact, our development teams always try new technologies in order to extend their knowledge base and practical experience. This allows MLSDev to offer innovative projects with the most outstanding user experience and the latest software development services.

Internal Project Goal

During the pandemic, and especially in quarantine, most businesses, their processes, and communication are being transmitted to the online form using software as a solution.

The initial goal of our internal project was to create a solution, a working prototype of a demo application for video calling, based on Twilio. This internal video conferencing tool could be applied in a range of industries and projects, and could be in high demand as a result of behavioral changes in online communication.

For instance, we projected our solution for a telemedicine app development or healthcare project and roles for patients and doctors.

High-Level System Overview

At the same time, the company was interested in testing a few backend technologies that are growing in popularity - the programming language Go, also known as Golang, and the Node.js platform, based on JavaScript.

Since the benchmarks state that these languages have quicker compilation and log capabilities, an investigation sought to test these aspects in practice. After exploring them, our team can now include Node.js and Go in MLSDev’s stack of software development technologies to meet the growing demand for these languages. In addition, we have compiled the pros and cons of each language and their best application for a specific requirement.

Project Description

The video conferencing platform developed consists of creating appointments, making and receiving video calls, and sending and receiving text messages. The system is available on the web and for iOS and Android mobile clients.

The internal project lasted for several weeks and has resulted in many interesting findings.

Video Conferencing Tool: Feature-Set

The software prototype includes the following functionalities with two conditional roles: "doctor" and "user."

• Login & logout
• Ability to create and/or cancel a call
• Ability to join a video call (only two participants; one doctor, the other client)
• Turn on and off the sound and/or video during a call
• Ability to switch between the main and the front cameras
• During an active call, the phone screen remains on even without user action

Check out the scheme below, showcasing the app flow.

App Navigation Flow

Next, you can check out some of the app screens presented on the web client. The interface is very basic, and it can be branded and adapted to meet the needs of a specific solution.

App Screens on Web

Aside from this fact, we can expand the prototype with more complex activities like multi-user communication support or custom-design elements.

Technical Details

We implemented the system so that any client application (iOS, Android, web) is compatible with any backend (Node.js and Go) via a common API contract. At the same time, it was decided that each backend would have a separate database.

We use WebRTC Video Rooms provided by Twilio to enable video calls in the system.

Below, you can find the general schema of connections between the system backend and Twilio.

Interaction Scheme between Twillio and Backend

Video call rooms comply with Twilio documentation. This means that:

• The first participant must be connected within 5 minutes after room creation
• The room is discarded 5 minutes after the last participant has disconnected

Here is a complete list of the technologies used in the project.

Findings & Experience Gained

As a result of this internal project, our development team now knows exactly how to utilize video conferencing functionality within any new project. The developers would have to simply allocate time to code refactoring to add this functionality.

Now it will take considerably less time to encode video conferencing functionality in new projects, especially for Go and Node.js technologies.

Pros & Cons of Go & Node.js

As a result of the project implementation, we have figured out the following benefits and potential drawbacks of using the Go and Node.js programming languages.

Here, we can advise on the best utilization of these programming languages.

Go

Pros:

• Go is a compiled and statically-typed language.
• Go compiles very quickly.
• Compiled binary works very quickly.
• The language is simple and allows developers to start working without spending a lot of time reading documentation.
• The standard library has a lot of useful things that cover almost everything, including network communication, database connections, etc.
• A large number of third-party libraries, like Gin, migrate, and validator, are available on Github.

Cons:

• Even though it is somewhat incorrect to compare a language and a frameworк - on Go, a developer has to write a much large amount of the source code, compared to Ruby on Rails.
• As a result, the probability of errors is much higher, and obviously, it requires more time.
• Error handling - a developer should be ready to receive “error” and “result” almost always and must check that the error is nil.
• The testing framework isn’t comfortable to work with as compared to Rspec.

Conclusions

The Go programming language is suitable for building small backends (microservices), especially if high performance is critical. However, as a developer, you must be ready to write a lot of boilerplate code.

Node.js

Pros:

• Easy to develop and easy to maintain code in TypeScript.
• TypeScript is more strictly typed, compared to JavaScript.
• Easy to deploy and scale by just running several instances on the server.
• Easy to test the code, both synchronously and asynchronously. It's easy to mock and stub objects or substitute implementation of particular methods.
• Lots of third-party packages are maintained by the community.
• The Async model in Node.js is organized in such a way that it allows for the processing of plenty of simultaneous requests.

Cons:

• Lots of imports in every file. Every single entity must be imported if it is defined in another file.
• TypeScript code is being transpired to JavaScript. This is a rare case that could lead to hard-to-find bugs or hard-to-interpret stack traces. This could be avoided by running TypeScript natively using ts-node.
• Lots of third-party packages. A developer should choose carefully because many packages are not supported anymore or could be dropped at any time.
• Not very good performance in hard computational tasks. Because of this, a developer should use other approaches so as not to impact server responsiveness. For example, use queues or message brokers.

Conclusions

Node.js is great for building microservices and highly responsive backends. However, you should be sure not to block the run loop so that your server will stay accessible. Also, it’s better not to rely on unknown third-party packages.

Utilization of Docker & Kubernetes

Docker and Kubernetes are DevOps technologies used for zero-downtime deployment and to successfully support software in regular updates. When the codebase changes to a more updated version, servers are reloaded. These reloads usually take some time and the server becomes unavailable,

The diagram below shows the basic setup of the server. As soon as a new release must be deployed, the current version of the backend is replaced by the new one. During this replacement, the server is stopped and can't handle user requests. However, this type of deployment is much easier than the zero-downtime deployment technique.

Basic AWS ECS Scheme

When using Docker and Kubernetes technologies, the server is always available.

Docker is a small virtual machine on your computer, and because of this, the system stays protected from any incompatibilities in libraries, configurations, etc. When you make changes to your computer directly, there is a risk of breaking something at the system level.

When using Docker, the developer can break it on the docker level, and in case of failure, a developer can reload it and reassemble everything once again with no influence on the system.

Our backend engineer wrote a Docker configuration that AWS uses to assemble a new image. Once a new commit is pushed to the repository, the building process is triggered. After that, the system is unfolded on servers for zero-downtime deployment.

So, how does this actually work?

We have two virtual servers, and each one has a separate docker container. These two servers turn to the same database, and on top of them, the application load balancer is included. The application load balancer accepts requests from mobile or web clients and spreads these requests between these servers.

AWS ECS Scheme with Docker

At the same time, a new container is created that is placed on both servers and is registered in a load balancer that now sees that there are four servers in total. The load balancer spreads requests out among these four servers, but it is actually aware that there should be only two servers.

As the new update is completed, the balancer closes the two older servers and redirects requests to new ones. Thus, the server works even during the deployment period and the process is called a zero-time deploy.

Challenges on the Way

The core challenge was to get around the Go and Node.js ecosystems and implement a fully-functioning video conferencing tool. These technologies are very different compared to our standard Ruby tech stack. There were many possibilities for failure, from connection with the database to error revisions.

Also, the log system on Go is more concise, while Rails systems log all the elements, web requests, requests to the database, responses, and crashes by default.

The Gin web framework, written in Go (Golang), used in this development was limited and logged only web requests. This variant is suitable for production as the logs are not over-spammed, but this is not effective for the development stage. In comparison, Rails logs everything, including requests with parameters, database queries with execution timings, etc.

This way, Rails-way dev logs contain all information for developers that simplifies debugging and fixing troubles. As a developer, you want to see what is happening and take direct code optimization and simplification actions. Therefore, once you utilize the mentioned framework, expect that you will have limitations during the coding process.