Infrastructure Requirements
This wiki page explains the general infrastructure expectations for running the reference Open Badges application. It isn't installation instructions, the intended audience is a systems administrator deciding what's necessary to support the application.
Some sections of this document are Mozilla specific and detail expectations for the beta release of the openbadges.org OBI installation.
- Learner / User - someone who has earned a badge.
- Issuer - an organization which issues a badge.
- Badge - an achievement, represented by a PNG file with embedded data.
- Baking - the act of embedding data in the badge PNG file.
- Assertion - a JSON file hosted by the issuer that describes a single badge and the learner it belongs to. This information is kept in plain text. The assertion includes a BrowserID identifier (an email address).
- BrowserID - the authentication framework used in the application. More information on BrowserID.
- Backpack - a learner collects multiple badges from many different issuers, the badges are kept in the OBI Backpack, a logical grouping of badges and the user that owns them.
The application is written in Node.js, and requires a MySQL database for storage. Several Node libraries are required, and are detailed in the package.json file.
The database stores user data, including the user's email address (a BrowserID required identifier), their associated badges, and any user defined grouping they've created for their badges. Badges include url's that point to the issuer's website.
We anticipate that the majority of the traffic to the site will be read heavy, as hosted backpacks will be shared via social media as proof of a learners achievements.
The initial beta release estimates several thousand users, but a small initial set of badges. Which will increase as more issuers come online.
The application is read heavy and will benefit a great deal from a reasonable caching strategy. Static assets are segregated and easily offloaded to a CDN. The backpack data api is still being developed, and is an easy target for application layer caching.
Given the read heavy nature of the data, directing reads to MySQL read slaves has the potential to lessen database bottlenecks. The datastore is capable of read / write splits, with some development.
Authentication is offloaded to BrowserID, but some personal information - badges and browserid associated email - is kept in the clear. No portion of the application currently requires SSL, but that may change.
The OBI consumes two services - an issuer hosted badge assertion (a JSON file), and the BrowserID authentication service.
The OBI offers two services, both currently in development - an issuer API that allows users to push issuer hosted badges to their OBI hosted backpack, and a backpack display api that allows a user to display their backpack on various services.
