** This page is currently DRAFT ** For a video overview of BigBlueButton, see https://bigbluebutton.org/html5.

    This document gives an architecture overview of the HTML5 client and how to setup a development environment and modify the client for your own needs.

    Architecture overview

    Client

    The BigBlueButtot client is a single page, responsive web application that is built upon the following components:

    • React.js for rendering the user interface in an efficient manner
    • WebRTC for sending/receiving audio and video

    The BigBlueButton server is built upon

    • Meteor.js in ECMA2015 for communication between client and server.
    • MongoDB for keeping the state of each BigBlueButton client consistent with the BigBlueButton server

    The MongoDB database on the server side of the HTML5 client contains information about all meetings on the BigBlueButton server. Each user’s client is only aware of the meeting the user is currently in and the communication and state, such as public chat messages and private messages between that user and others.

    The following diagram gives an overview of the architecture of the HTML5 client and its communications with the other components in BigBlueButton.

    HTML5 Overview

    The client uses the SASS precompiler to keep the stylesheets short and readable. SASS is a stylesheet language that is compiled into CSS.

    The responsive UI of the HTML5 client is constructed using media queries. Each SASS expression is tied to some specific range of devices and window sizes.

    All the code for the HTML5 client is inside the bigbluebutton/bigbluebutton-html5/ folder.

    Server

    As we start the Meteor process in the terminal, we initialize RedisPubSub and then publish a json request message “get_all_meetings_request” to BigBlueButton-Apps, which triggers the following response:

    {
       "payload": {
         "meetings": [
           {
             "meetingID": "183f0bf3a0982a127bdb8161e0c44eb696b3e75c-1415134791204",
             "meetingName": "Demo Meeting",
             "recorded": false,
             "voiceBridge": "70827",
             "duration": 0
           }
         ]
       },
       "header": {
         "timestamp": 3350491563,
         "name": "get_all_meetings_reply",
         "current_time": 1415312516720,
         "version": "0.0.1"
       }
    }
    

    We parse this information and populate a Meetings collection on the server side (stored in MongoDB) for all the ongoing meetings on this BigBlueButton server. Similarly we obtain an array of all users, presentations and the chat history for each meeting. Using this information we populate our collections Users, Chat, Presentations, Shapes, Slides, etc. We are subscribed to receive event messages on the following Redis channel:

    • “to-html5-redis-channel”
    • “from-akka-apps-*”

    And we publish event messages on:

    • “to-akka-apps-redis-channel”

    Throughout the meeting we keep receiving json messages via Redis about all the events in the meetings on the BigBlueButton server. The handling procedure typically involves updating the particular document[s] in the collection.

    The BigBlueButton Flash client can detect if the HTML5 client is installed and available on the server by making a GET request to http://your_ip>/html5client/check and receiving {"html5clientStatus": "running"}.

    Consistency of state

    We rely heavily on the fact that MongoDB on the server side automatically pushes updates to MiniMongo on the client side. The client side subscribes to the published collections on the server side. During the subscription, the meetingId, userId and authToken of the user logged in the client are required. These 3 identifiers provide enough information for the publishing mechanism to decide what subset of the collections the user logged in the client is authorized to view.

    If a user loses connection while in the meeting, a message appears on the screen informing the user about the disconnection and the reconnection countdown. The client will periodically attempt to reconnect. If the reconnection is successful, the client will reappear with everything up to date.