Futility is currently a client-server architecture. Because the calculations we compute are fairly memory-intensive, we can't perform all of the processing in the browser. Similarly, since the tools for building these simulations are easiest to use in the browser, we can't easily do all of the work in an offline tool.
The components are split into three parts:
The server has a dependency on the analytics code, and serves the web-based front end.
futility-js is a Javascript front end that manages analyzed data sets and their visualization. It uses d3 for calculating scales and providing axis. The visualizations are generated using svg elements and react to manage updates to what is visible. griddle-react is used to create the table for comparing fitness in the face of various treatments. Redux helps manage complexity when updating the state of our analyzed data sets, and jspm is our build tool. We use jQuery to manage our AJAX interactions with...
futility-server is a Clojure server interface in front of futility-lib. It runs a ring server that listens on the HTTP route "/futility". Requests on this route are parsed into the appropriate classes using Gson. Once the results are returned from futility-lib, they are serialized to a JSON string using Gson. A rewrite has moved to persisting the imported data on disk to conserve memory - we write the sequence measurements out as JSON files, and insert the features into a database to facilitate the fitness table.
futility-lib is the library responsible for performing analysis on raw data. It is written in Java, and takes some very simple structures, performs analysis, and then returns similarly simple structure. We use a handwritten multinomial sampling method (possibly ripe for optimization) and we use the mannWhitneyU methods available in commons-math3.