Architecture Overview

Learning Locker is divided into two Github repositories, one for the Learning Locker application and one for the xAPI service.

In Learning Locker the Browser Interface, HTTP Interface, and xAPI Service use their own HTTP ports, hence we’d recommend that you use a server such as NGINX to route to the correct port upon receiving HTTP requests. If you utilise the installation command provided in the installation documentation, it will attempt to install and setup NGINX for you. The installation command will also use PM2 to manage your processes and restart them if they exit to ensure uptime.

LEARNING LOCKER APPLICATION

The Learning Locker application repository is made up of three parts (in the same Github repository), the browser interface (UI), the HTTP interface (API), and the workers. The three parts are ran as their own process to share resources (since JavaScript is single-threaded) and ensure a degree of redundancy.

BROWSER INTERFACE (UI)

The browser interface is written in JavaScript (ES6 using Webpack and Babel), utilising React to construct views and Redux to manage state. The browser interface utilises the HTTP interface to retrieve and change models in Learning Locker. Note that all models automatically save within 3 seconds after they’re changed. For more information and help with the browser interface, you can go to the Help Centre for Learning Locker.

HTTP INTERFACE (API)

The HTTP interface is also written in JavaScript (ES6 using Webpack and Babel) and uses Express, Restify, Mongo, and Mongoose. Express is used to provide HTTP routes and Restify is used on top of Express to provide RESTful routes for each of the models in Learning Locker. Mongoose is used on top of Mongo to manage models in the Mongo database used by Learning Locker.

WORKERS

The workers are also written in JavaScript (ES6 using Webpack and Babel), they utilise Redis and optionally SQS via queue drivers. The workers make use of queues to process long running jobs. Multiple instances of the workers can be used in a cluster to process the queues in parallel across many machines and processors.

Currently there are workers for managing the query builder cache, extracting personas from statements, exporting statements via CSV, importing personas via CSV, and (in Enterprise) recalculating journeys.

XAPI SERVICE

The xAPI service is made up of four parts: statements, activity profiles, agent profiles, and state. The xAPI service provides access to the xAPI HTTP Interface for interacting with the xAPI as defined in the specification. The service is written in entirely TypeScript and primarily uses Express, Mongo, and Redis.