Thanks to Akshay Gugale for this picture, a fantastic designer.
This is Part I of the Video Calling App blog series. You may want to check other posts on the main blog post here.
To build this video calling app, we’re not going to reinvent the wheel of WebRTC and audio/video communication. Instead, we will use Dyte SDK. Dyte is a Software-as-a-Service that provides an abstraction over WebRTC communication with some added features that take away our headache related to scaling and managing infrastructure resources required for a typical WebRTC call.
Ideally, we can build a single web app using any framework and get away with it. However, to make our application a little more secure, better to scale, and easier to manage, we will build it in 2 parts: (1) a Backend and (2) a Frontend. Otherwise, how would we be able to authenticate attendees with our own system and provide access to them depending on authorization?
This is not an architectural diagram, but our application will look like this:
Now, let’s explore the components of this solution.
Backend (or Middleware)
In our app, the backend (or middleware) aims to handle all logistical tasks such as user management (registration, login, password reset, account closing), meeting scheduling, listing recording, etc. It will also help us build our logic based on Dyte REST APIs. For example, Dyte API allows adding participants to the call, but who should be able to attend the call will be our responsibility. Our Backend APIs will help us to manage that aspect.
I will write this middleware/backend as ASP.NET Core Web API using C#. It has been a while, and this will give me a chance to revisit my old territory :)
Irrespective of the language, and framework, the flow will remain the same.
Frontend (or App)
Again, the flow will remain the same irrespective of the language and framework.
Okay, but what is the flow?
A typical flow for a video app is someone creating a meeting or initiating a call and another person joining that meeting or call. However, there are a few steps in between when it comes to implementation. Let’s understand those.
Step 1: Create a Dyte account: This will give us the required credentials.
Step 2: Call Dyte REST API: Create Meeting
Step 3: Call Dyte REST API: Add Participant
Step 4: Join the meeting
Step 5: Inviting someone to the call
Step 6: Repeat Steps 3, 4 & 5
Once the meeting is created, and the participant is added, the front end directly talks to the Dyte infrastructure to manage the call. The backend can still communicate with Dyte infrastructure through REST APIs and subscribe to events using Webhooks.
Dyte REST APIs (Dyte Backend)
Our backend will call Dyte REST APIs to create a meeting and do various operations around it. Dyte REST APIs and Dyte SDKs are the backbones of our application, and we shouldn’t be exposing those directly through our app. That’s why we introduced middleware.
There are still a few more components to this app that I am not showing at this moment to avoid getting overwhelmed. For example, we will be using Table Storage to store meeting information, for example, who is invited and who has access to the meetings. We will also be using third-party authentication services to make sure only invited users are authorized or allowed to join the meeting. We’ll cover those services when we get to the point where it is necessary to talk about them.
I am excited about this project. Are you?
Let’s meet next week to talk about Dyte REST APIs and how to call those.
Till then, happy coding :)