teleport- technical project brief
Styled-components + Ant Design for UI components;
MobX for global state management and efficient components update (reactions);
AVC for publishing streams and subscribing to them;
Socket.io-client for real-time updates and support of server-side avc features;
Axios for API calls.
The front-end application is divided into the following parts:
UI components that can be used on multiple pages. Contain the majority of the interface and some logic;
pages that combine UI components and bring in handlers for logic from services. All pages have a corresponding URL, e.g. “/feed”, “/call/incoming”, etc;
services that are used for multiple purposes and usually domain-oriented (a chunk of business logic);
interfaces, constants, functions-helpers, and other helping utils.
Socket.io-client is used for the following features:
joining the lobby and tracking online/busy users so that you can make random/specific calls;
initiating a call (with room) and tracking its status and participants;
passing data between call participants and viewers, such as user information, published streams, status, etc;
in-app notifications (missed calls, friend requests, etc);
comments for both “live” call and feed;
exchanging data for mixers functionality (as well as recordings).
Global service is responsible for:
initializing all necessary components and other services;
storing and updating user information and contact list;
sending, removing, and tracking (receiving) in-app notifications (socket);
initializing media (from media devices);
initializing “avc cloud”;
joining the “lobby” and tracking “online” and “busy” statuses of other users (socket);
initializing both random and specific calls and tracking incoming calls (socket);
joining the call room (for both incoming and outgoing calls);
joining the room for comments (on “feed” page);
AVC Call service + Incoming/Outgoing services
Those services are responsible for (most of these use socket):
publishing streams to avc cloud and sending streams’ data to other participants;
tracking other participants’ streams and subscribing to them;
updating stream’s kinds (“video”/”audio”);
sending the mixer’s layout for recording and “live” calls;
storing other participant’s data;
tracking viewers connect/disconnect (currently not used);
sending status and tracking statuses from another participant, such as “no response”, “missed call”, “declined call”, “accepted call”, etc;
leaving the call. That will stop all streams, send corresponding statuses, leave the socket room, and reset the rest of the data in the service.
Live service is responsible for:
joining “live” room;
subscribing to the mixer’s stream;
leaving the call (similar to the AVC Call services);
Comments service is responsible for:
subscribing to the comments (tracking) in the room. Note: the socket has already joined a target room according to Global service’s logic so that this service doesn’t know (and shouldn’t know) about the room we are in;
fetching old comments from the database (is used for viewers in “live” calls and on the “feed” page). Fetch is used with endless scroll (will be described later on the article);
Feed service is responsible for:
loading the list of recordings (with endless-scroll as well);
loading the shared recording (based on its id) and cleaning it when needed;
tracking a current recording;
calling a global service method to join a current recording’s room (to be able to subscribe to comments and send them);
1) Comments block (component) and feed use “endless scroll” which means they will load a chunk of the data and then will load the next chunk when the threshold is reached while scrolling.
2) Feed page uses a “scroll snap” which allows users to easily scroll to the next recording.
3) The “private router” component is used to track if users are allowed to open some of the pages. For example, if a new user opens a shared link (“recording”/”live”) they will be redirected to the “logic” page first and after successful authentication will be allowed to pass to the desired URL.
4) When a new user opens some pages, he will get a “hint” that will help him to understand better how this page works.
5) To let the Feed service track the current recording, the Interaction Observer API was used.
6) All pages are “lazy” loaded which gives a drastic decrease in the size of the main file that is loaded by the user’s browser when they open a website. All other pages are loaded later when the user browses on them for the first time (thus, we have a loader screen indicating that the requested page is loading).