Statuses
Statuses is an experimental, extremely simple-minded microblogging infrastructure for internal use, basically created to have a small yet meaningful Clojure app to play with. Don't expect too much, certainly not something ready for production unless you're mainly interested in fiddling around with stuff.
How to for developers
- Make sure you have a reasonably recent Java runtime. Statuses has been tested with JDK 7, but should work with JDK 6 as well (and possibly even JDK 5).
- Grab Leiningen (we've just upgraded to the Leiningen 2 preview and suggest you use this) and install according to its instructions
- Clone this repository
- Use
lein run
to start the application, then access it at http://localhost:8080 - some sample data is auto-generated if the "database" is not found - Use
lein test
to run the test suite - If you want to create a deployable artifact, use
lein uberjar
to create a stand-alone .jar file that you can run withjava -jar <name>
If you want to run the application from clojure REPL e.g. in IntelliJ IDEA, you can go like this:
- open a clojure console/ REPL prompt in the "statuses" root folder
- you should see
user=>
- type
(load-file "src/statuses/server.clj")
- type
(ns statuses.server)
- type
(-main nil)
This should start the server.
Dependencies
Statuses uses
- Compojure for URI routing
- Hiccup for HTML and XML templating
- clj-time for time-related stuff
- clojure.data.json for JSON support
Note that all these dependencies are fetched automatically when you
use lein run
for the first time, and are put into the uberjar for
deployment.
Design notes
Persistence
Given its very limited initial requirements at @innoQ (and to support its usability as a self-contained example), the most significant design decision within Statuses is that no database is used. Instead, all of the status updates are kept in memory and are persisted every minute. This works surprisingly well in terms of code simplicity, but will obviously scale only within limits. But if you assume 15k are needed for every 100 status updates, even a million of them would fit in 150MB of JSON (and probably something similar in memory, haven't checked yet).
If scaling problems arise, it's likely going to be because writing the DB to disk takes too long (though even that might be doubtful given today's disk speeds). Should that become a problem, a solution might be to combine the in-memory DB with an event-driven model, where the full memory dump is only written very rarely, but every status update is persisted immediately (essentially a transaction log). The full state could thus be restored from the events stored, adding yet another buzzword and turning this an event-sourcing model. But seeing how far one can get without actually using a "real" database is part of the experiment.
So there are currently no plans to change the db model, even though
refactoring the persistence into a Clojure protocol
might be
reasonable to allow others to implement different backends.
Modules
Currently, the structure of the whole program is still very simplistic and should probably be refactored soon. At the moment, code is split across the following namespaces and matching files:
statuses.server
: the server main entry pointstatuses.backend.core
: the in-memory data structure and related functionsstatuses.backend.json
: JSON utility functions for converting the in-memory DB to and from JSONstatuses.backend.persistence
: functions to write and read the DB to/from diskstatuses.backend.time
: utility functions for handling the conversion of (localized) time stampsstatuses.views.common
: layouts (using Twitter Bootstrap) for the UIstatuses.views.main
: the actual UI elements for displaying HTML (and JSON)statuses.views.atom
: function to provide an Atom 1.0 feed of status updates
Author information and license
Copyright 2012 innoQ Deutschland GmbH. Published under the Apache 2.0 license.