The (Python?) back-end is responsible for processing requests & handling the actual business logic, such as creating orders, charging credit cards, updating website inventories, etc.


Building the application so it can be manipulated via a REST API could help us eventually decouple the front- & back-end and allow an easy interface for keeping multiple instances in sync.

CLI, GUI & mobile applications could be developed to interact with a remote instance's REST API (in a future far away).

Instances could designate peers or a central authority which communicate via a REST API. An instance could ask another instance that is designated as a central authority to update a value or pull new information through the API.


A Websocket is a constant connection between a client browser & the server instead of the atomic request/response cycle of standard HTTP. This lets the server push real-time updates to the client. So new orders automatically show up in every browser as they are created, other users can instantly see when an order is shipped or approved, etc. The usual alternative to simulate real-time updates is contantly polling the server using AJAX requests.

This could also be used for something like application-wide chat.

Usually websockets works directly with a message queue server like redis instead of the usual database.

Totally supported by Javascript & Haskell, Django has support but some recommend running Tornado next to Django.

Object History

We should definitely have a simple audit/changes/activity log, showing datetime, item, changes(if possible), and maybe a description of the changes.

A per-object history would be ideal, showing all previous states of the object(maybe through diffs or highlighted/side-by-side detail pages?). That should make it possible to let users revert the object to a previous state.

The ideal feature would be the ability to map changes to actions and to execute the actions when rolling back a change. For example, when an order is reverted from a "paid" state to an "unpaid" state, we could have the program automatically issue a refund.

That could potentially get messy, but it wouldn't be needed on too many models.

For python see: django-reversion and the model auditing grid.

For haskell, we could store diffs of the JSON using Aeson.Diff or diffs of the Persistent Models using Data.Generic.Diff


A simple front-end would be HTML, CSS & Javascript generated by the back-end.

Another possibility is having the back-end generate a context which is passed to Javascript that generates the page on the users browser. The front-end's rendering code would live in the Javascript, instead of being embedded in the back-end.

React and Elm seem like good possiblities for a decoupled front-end(as of 3/2015). (Also Ember & Angular)