Once [[ https://phabricator.wikimedia.org/T206010 | questions about the external interface have been answered ]], we'll need to plan the remainder of the implementation, including the use of technologies, and operational semantics.
## Mediawiki Integration
Mediawiki supports plugging of session persistence using a `BagOStuff` implementation, and there already exists a [[ https://doc.wikimedia.org/mediawiki-core/master/php/classRESTBagOStuff.html | `RESTBagOStuff` ]], (apparently [[ https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/293554 | created for this purpose ]]). The only issue with [[ https://doc.wikimedia.org/mediawiki-core/master/php/classRESTBagOStuff.html | `RESTBagOStuff` ]] is that it uses PHP's [[ https://secure.php.net/manual/en/function.serialize.php | serialize() ]] and [[ https://secure.php.net/manual/en/function.unserialize.php | unserialize() ]] for the body of `PUT` and the response of `GET` respectively, and we have specified JSON. Options include: Updating the existing implementation as a breaking change, update the existing implementation to support optional (configurable) JSON encoding, or creating another implementation based on [[ https://doc.wikimedia.org/mediawiki-core/master/php/classRESTBagOStuff.html | `RESTBagOStuff` ]].
## Replication semantics
Based on the requirements for session storage, we should be able to assume in all cases that `GET` and `PUT` use Cassandra's `ConsistencyLevel.LOCAL_QUORUM` and that `DELETE` uses `ConsistencyLevel.EACH_QUORUM`.
NOTE: The software created to implement this will be a very straightforward key-value implementation, likely applicable to other use-cases in the future, not all of which will necessarily be satisfied by these semantics. However, rather than generalize this now (either through configuration, or per-request parameters), we will define these as constants, and revisit when/if a future use-cases arise.
The raison d'etre for this service is session storage, so security is paramount. However, with NodeJS, the only practical source of dependencies is http://npmjs.org. Dependencies, both those explicitly declared, as well as those that are transitive, are fetched whenever `npm install` is invoked, and there is no chain of trust. These dependencies -- the entire contents of `node_modules/` -- are as much a part of our production applications as any that we write, yet despite the time, care, and effort we put into reviewing even the smallest of changes to our code bases, the contents of `node_modules/` remain opaque to us.
A saner approach for something so security critical, would be to prioritize a manageable list of dependencies that can be sourced entirely from within our current version of Debian (Stretch).
| | Debian-sourced dependencies | Tooling | Ease of coding | Operational complexity | Cassandra driver |
| ---- | ---- | ---- | ---- | ---- | ---- |
There seems to be more of a precedent for building software like this in Python, //!!not in Debian!!//) |
| PHP | Possiblythan there is for PHP, here at the WMF. Additionally, sort of (if package in Sid is fixed and uploaded to backports) | ???a Cassandra driver is packaged for Debian Stretch, | Very | FastCGI integrated w/ Nginx/Apache(?) | Good;as are most (all?) of the common frameworks, a prometheus client, //!!Only present in unstable ([[ https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865271 | and it is broken ]])!!// |
| Python | Yes | Djangoand several high-performance production ready WSGI containers.
Of the popular frameworks in Debian: [[ https://www.djangoproject.com | Django ]] seems a bit heavy/excessive for a service this simple. [[ http://flask.pocoo.org/ | Flask ]] is much simpler/lighter, yet seems to have the abstractions that would matter to us (logging, configuration, JSON encoding/decoding, Falconetc), Fand is [[ https://qa.debian.org/popcon.php?package=flask, | quite popular. etc | Very | | Good;]] It also helps that this would [[ https://debmonitor.wikimedia.org/source-packages/flask | not be the first use at the WMF ]].
(NOTE) My (@Eevans) preference would to implement this service in Python (v3) and Flask, v3.7.1 in Stretch (v3.14.0 in Sid) |using dependencies sourced from Debian Stretch. Input from SRE on this would however be appreciated (/cc @faidon, @Joe, @MoritzMuehlenhoff ).