Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.

Goals & Criteria

  • Broadly approachable
  • Hit the ground running
  • Interoperable
  • Scalable and forward-looking
  • Fits the approach of the Fluid community: functional, declarative, Web-oriented


Lastly, the Fluid community has built up, over the years, a set of techniques and philosophies for writing software: accessibility, the Open Web, functional programming, and markup agnosticism are common themes throughout our technologies. As a community, we embrace diversity and a wide range of styles; shared patterns and techniques in code help make our solutions more coherent and consistent to develop with.

Some Background Information

We explored a variety of potential technologies for the Engage services layer. In each case, we considered both a programming language and an accompanying Web framework, recognizing that much of the advantage of a particular language comes from good tools we can reuse. We looked at solutions in Python, Ruby, PHP, and JavaScript running on the server.


In-depth information about our approach to evaluating technologies, along with our observations, is available at the Fluid Engage Server-side Technology Notes page.

CouchDB and Lucene

Data Feeds and CouchDB

There is an incredible amount of diversity among museums in terms of how they each organize their collections and structure their data. Each museum's collection is different, and it is a daunting and risky task to attempt to force all types of collections into a single schema. Engage will need to embrace this diversity; rather than creating a "one size fits all" approach at the database level, we'll take a flexible approach to schemas in Engage.


Written in Erlang, Couch is extremely scalable and can meet the requirements of massive, complex collections and exhibit data.

Free Text Searching With Lucene

Users have come to expect natural, Google-like text searches from most modern Web experiences. As a result, Engage will need to include a free text search engine service.


We will continue to assess Lucene's associated Solr project, which provides a RESTful API and JSON-based wire protocol ideal for Engage's architecture.

JavaScript on the Server

JavaScript is traditionally considered as a client-only language, running mostly in Web browsers. A number of runtimes do exist that enable JavaScript as a general-purpose programming language, and most modern browser engines can be compiled as standard libraries for use on the server.


JavaScript on the server, while still on the bleeding edge, provides us with an broadly approachable environment for writing server-side code using many of the existing tools offered by Fluid Infusion.

Rhino and the JVM

Currently, the most mature and reliable environment for running JavaScript on the server is Mozilla's Rhino. Running with a Java Virtual Machine, Rhino is used widely for embedded scripting in many Java applications, and also ships as part of the standard Sun Java 6 JDK. As a result, Rhino is widely tested and stable.


Where necessary, we can also leverage other libraries that are available in Java. However, to be very clear, we will limit our use of Java within the Engage services layer to only situations requiring extremely fast performance (such as converting data in bulk) or to clear, easy-to-port algorithms.

Next Generation Runtimes

In the past, JavaScript has been regarded as a slow scripting language. With the browser wars back in full swing, new JavaScript runtimes have emerged in the latest releases of every major browser. Even more than any other scripting language, JavaScript VM optimisation is receiving very significant attention.


The long term roadmap for the Engage services layer will be to move from Rhino on the JVM to one of these next-generation JavaScript runtimes. While there are Web server adaptors for both runtimes available today—most prominently v8cgi—we expect it will take a number of months before these are production-ready. As soon as we're confident in the concurrency, cross-platform support, and reliability of using a next-generation runtime for server-side Web development, we'll switch. In the meantime, Rhino and the JVM will provide us with a stable and acceptable production environment.

Portability and JSGI

With a plan to build first on Rhino and the JVM, and move to a next-generation runtime as soon as the required Web infrastructure is established for one of these, the obvious problem is portability. If we commit to Rhino now, will be able to move to V8 or Tracemonkey later?

The JSGI spec provides a solution to the portability issue. Modeled after Python's WSGI and Ruby's Rack, JSGI provides a simple contract for containers when managing requests and responses. JSGI is well-suited to JavaScript's functional style, and is relatively straightforward to implement. By coding to JSGI, the Engage server-side technology can be trivially ported from Rhino + Servlets to V8CGI or another next-generative runtime.

Env.js for Browser Compatibility

One of the goals of JavaScript on the server is to provide a natural and easy-to-learn environment for developers who are familiar with client-side JavaScript programming in browsers. We'll also want to be able to reuse the existing Infusion components and framework without having to modify the code to run on the server.

John Resig's Env.js provides us with the ability to support common JavaScript browser features that are typically missing on the server, including the DOM, local and remote AJAX, and the use of libraries such as jQuery. Inevitably, only a subset of these tools will remain relevant on the server, but Env.js ensures maximal reuse of existing code, making it easy to start developing in this new server-side environment quickly.

Tying it all Together

The Engage services layer will weave together a variety of existing technologies to create a new server-side Web development framework called Kettle. Using Rhino and Servlets, we can easily establish a JavaScript-based Web container, and we'll follow the JSGI spec to ensure its portability to v8cgi and other environments. Env.js will provide us with an interface for standard tasks such as making HTTP requests and file manipulation on the server, all wrapped in a browser-like API familiar to most JavaScript developers. Fluid Infusion will provide us with a framework for most common application framework features such as data binding and events. The only substantial new code we'll write is a URL routing scheme, most likely inspired by CherryPy's approach. With this, Kettle will offer a full-featured framework for server-side development.


Using JavaScript on the server side to build the Engage services layer is unconventional approach and not without its risks. That said, it provides us with a number of compelling benefits. This architecture...

  • is familiar and broadly approachable, both by our community and by the majority of Web developers
  • allows us to reuse existing code and infrastructure such as Fluid Infusion, allowing us to get started fast
  • enables us to deploy components and markup either on the client or the server, based on device or app requirements
  • can scale to meet the needs of museums with large collections and many users
  • is unlikely to become obsolete in the future
  • Assemble our own framework Kettle by combining JSGI, Env.js, and Infusion