How we are building the next big thing in video conferencing. Part 1: Pivot and microservice architecture.

The story of Proficonf began in 2016. We’ve decided to build a web-based service for e-learning and consulting.

The service is a platform for conducting teaching and consulting activities with the help of video calls in real time via the Internet

Basically, this was the first description of the app, we used it in a job description for developers.

But then, in April 2017 we’ve decided to make a pivot to video conferencing/webinars. Our main goal was to create a lightweight and powerful tool at the same time. The tool that doesn’t need installations or downloads and has the capacity of top-players in video conferencing market. That’s why we’ve decided to use WebRTC to build our product around.

Key features of the app:

• Browser + Internet (128 kbps min, 512 kbps recommended) is the only thing you need to use the app, no additional downloads needed.
• Upload and share files of any format with a size up to 500 MB.
• Unlimited storage of files and access to them from any conference.
• Record your meetings, download the video or share it with participants right away.
• Create a permanent “conferencing room”, and use the same URL repeatedly.
• Synchronized display of documents of any format. Highlight and mark the important parts in a built-in tool.
• Demonstration of video and audio files. Fully synchronized playback of media files on a lightweight player of any format, search and play videos from Youtube.
• Share not only your screen, but also native apps, and browser tabs.
• Up to 500 participants in the “room”.

Source code:
3744 commits
535 call-back accounts
70,000+ lines of custom code
1161 files

Microservice architecture:

Initially, the project was a classic and monolithic "The Rails App", though the views were originally designed using Angular.js. Approximately like this:

With the advent of new functionality, the application grew like a snowball and it was already very difficult to support it by a small Ruby group of developers who had to be also experts in javascript / angular.js so it was decided to start a micro service architecture and firstly break it into 2 parts: front-end and back-end.

The real value of the microservice approach is not even that it allows the breakdown of the logic of a large application into small services with its own area of ​​responsibility, but that this approach makes it easy to scale a team of project developers into cohesive small groups.

In the course of execution of this plan, we met a couple of challenges:

• Gently pick up the work with the VIEW application from RoR, get rid of sprockets and assets pipeline, as much as possible “lighten” the Rails App and make it into a Thin API Server.
• Add the dependency system (npm) and the application assembly (gulp) to the front-end component.

But further history showed that this decision was justified. It turned out to create 2 departments that functioned well, both internally and among themselves.

The idea of microservice architecture has taken hold and we soon saw the Instant Messages (IM) service from the Ruby team.

Instant Messages — is a service that delivers instant messages and notifications to user from the application. It is based on the non-blocking EventMachine process which continuously proxy and route API messages (and other microservices) to the browser. The service uses 2 types of transport: RabbitMQ and WebSocket.

At this moment we have more than 10 microservices and the number of them continuously increases with each month. Microservices enable us to develop the functionality in isolation, which has a positive effect on productivity.

We want to give you some practical advice on designing microservices:

1. You don’t need to design a microservice architecture of the application simply because it’s a mainstream approach. The most important thing it’s not necessary. Especially in the early stages of development. Let your application grow into something more independently.
2. Don’t think about what language to use in a service, think about what problems it solves and what functions it performs.
3. When designing a service and its connections, you represent objects or personalities from the physical world. We imagine the operator and the editor working in pairs and as a result, we get clarity in the demarcation of the functional and the way of communication with the microservices.

In Part 2 I’ll tell how we managed to expand our architecture, and what challenges we met.