JavaScript Shell
Latest commit 4a435ca Jul 17, 2018
Failed to load latest commit information.
debian Document Cassandra datacenter configuration Sep 15, 2015
doc Handler specs 2.0 Nov 19, 2015
lib Deduplicate most-read results, pt. 2 Jul 16, 2018
maintenance Separate mobileapps switch to the new bucket Sep 20, 2017
projects Expose Javascript endpoint Jul 13, 2018
sys API: Include anchors in redirect targets Jul 10, 2018
test Deduplicate most-read results, pt. 2 Jul 16, 2018
v1 Deduplicate most-read results, pt. 2 Jul 16, 2018
.dockerignore Added a .dockerignore Oct 23, 2015
.eslintrc.yml Use common ESLint config Sep 30, 2016
.gitignore Separate mobileapps switch to the new bucket Sep 20, 2017
.gitreview Add .gitreview Oct 29, 2014
.jscs.json Separate mobileapps switch to the new bucket Sep 20, 2017
.jshintignore Exclude npm debug log from git, coverage from jshint Jan 9, 2015
.jshintrc Relax definition order of functions Mar 3, 2015
.travis.yml Travis: Disable NUMA and use Cassandra v3.11.2 Jun 20, 2018
LICENSE Switch to Apache2 & link to phabricator / wikimedia repo Feb 14, 2015 Fix sandbox URL in Sep 12, 2017
config.example.wikimedia.yaml Change example x-sub-request-filters to accept https only Jul 11, 2018
config.example.yaml Hygiene: Always use https for wikimedia/wmflabs URLs in example configs Jul 10, 2018
config.test.yaml Added tests for HTML language variants Jun 19, 2018
index.js Re-export hyperswitch as the main package entry point; release v0.15.0 Aug 22, 2016
package.json Release v0.19.1 Jul 17, 2018
server.js Stop using deprecated Feb 1, 2017

RESTBase Build Status Coverage Status

RESTBase was built to provide a low-latency & high-throughput API for Wikipedia / Wikimedia content. It is basically a storage proxy, which presents a coherent API powered by Swagger specs to the outside, and backs up many of these entry points with storage. The default table storage backend is based on Cassandra, which helps it to perform well at Wikimedia's scale without placing undue burden on operations.

As a proxy, RESTBase does not perform any significant content processing itself. Instead, it requests content transformations from backend services when needed, and typically (depending on configuration) stores it back for later retrieval. For high-volume static end points, most requests will be satisfied directly from storage.

The table storage backends conform to a RESTful table storage API similar to Amazon DynamoDB and Google DataStore. The primary implementation uses Apache Cassandra. Notable features include automatically maintained secondary indexes and some lightweight transaction support. A SQLite backend is under development.

RESTBase systematically emits statsd metrics about storage and backend requests. Specifically, the systematic metric production for backend services provides a good baseline level of instrumentation for tracking performance and errors in a micro-service architecture.

Issue tracking

We use Phabricator to track issues. See the list of current issues in RESTBase.


Make sure that you have node 4+:

sudo apt-get install nodejs nodejs-legacy nodejs-dev npm

Note: if your distribution does not have a recent version of Node, you can install one via nvm.

From the restbase project directory, install the Node dependencies:

npm install

Start RESTBase:

node server

The defaults without a config file should work for a local Cassandra installation with the default passwords. Restbase has been tested with Cassandra 2.2.6. To customize RESTBase's behaviour, copy the example config to its default location:

cp config.example.yaml config.yaml

You can also pass in the path to another file with the -c commandline option to server.js. If you're running a single Cassandra instance (e.g. a local development environment), set defaultConsistency to one in config.yaml.


See the Wikimedia REST content API sandbox for a fine example of what RESTBase can do.



To run all the tests from a clean slate, first make sure Cassandra is running locally, then fire up the tests with npm:

npm test

To run tests from a single file, e.g. test/features/pagecontent/rerendering.js, run mocha with the file as an argument:

mocha test/features/pagecontent/rerendering.js

Note that this might require some setup (e.g. creating the necessary domain and buckets), which is currently done by test/buckets.js.

This also works for a directory, e.g. test/features/pagecontent/:

mocha test/features/pagecontent


To check the test coverage, use npm, then browse the report:

npm run-script coverage

The coverage report can now be found in <project>/coverage/lcov-report/index.html.

Design docs