Origami: Component-Based Web Applications

Andrew Betts, director at FT Labs, presented to Velocity Europe 2014 attendants a set of home-grown standards and tools for web development. They aim to cope with the development challenges of creating and maintaining more than eight hundred *.ft.com sites. FT Labs main strategy is to breakdown web pages into components built within a well-defined set of rules.

FT Labs is a Financial Times team focusing on web technologies. The fast growth of Financial Times digital assets led to a number of challenges, all related to scale. The sheer number of different web sites without common, structured rules and tools means a lot of repeated work. An ever growing, ever more complex web ecosystem induces significant drag: hard to maintain and evolve web applications; legacy code that is impossible to decommission; convoluted application integrations; hard-to-find, end-to-end engineering skills requirements.

So FT Labs set out to find a solution that tackles those problems and settled upon a component-based approach. A set of principles underpin the solution. Some of them are as follows:

1. Everything should be governed by standards
2. Components should not be special cased to a single product (i.e. web site)
3. Components should be easy to use and non opinionated
4. Component consumers should control the upgrade timing of the components they use
5. Components should be encapsulated or namespaced so they do not interfere with their “web neighbours”
6. Dependencies on external systems should be minimised, so the overall solution is more reliable and faster to ship.

Components come in two flavours: modules and web services.

An application built with Origami components (originally published at the Origami web site).

Modules are static resources (e.g., CSS files) or CommonJS modules, so their main purpose is to provide a consistent UI experience across web sites. Each module must follow a specification that touches on naming conventions, package and build configurations, tests and demos rules, among other requirements. Examples include o-grid, a grid for responsive layouts, o-date, for date formatting and updating, or o-ft-typography, for FT brand-specific typographic styles. These modules’ documentation showcases what is possible by following the specifications.

Web Services, as the name implies, provides content and data through an URL endpoint. Web services must also conform to a specification. The specification defines several requirements, such as deprecation rules, required endpoints (for health checks, metrics and documentation), versioning rules and multiple web services environments rules. The responsive-image-proxy, a proxy for resizing and optimizing images, is an example of a Origami web service.

Origami provides a build service for modules. The build service is usually triggered at runtime. If a web page contains <link> tags like these:

<link rel="stylesheet" href="//build.origami.ft.com/bundles/css?modules=o-ft-icons@^2.3.1" />

The build process will:

1. Install version 2.3.1 (or updates up to the next major version) of the o-ft-icons module
2. Install all its dependencies, if it happens to have any
3. Run the build process
4. Minify the CSS output
5. GZip it & cache it
6. Serve it through a CDN

There is also an equivalent Javascript build process that is triggered via script tags.

FT Labs provides a component’s registry that can be used by anyone, although some components are Financial Times-specific, as we’ve seen.

Andrew finished his talk by presenting FT Labs’ Polyfills as a Service. Polyfills is Javascript code that adds feature unavailable natively on a web browser, thus smoothing out the differences between vendors and versions. The service is customizable, but using it can be as simple as including this script tag in the web page:

<script src="https://cdn.polyfill.io/v1/polyfill.min.js"></script>