CommonJS/JSGI: The Emerging JavaScript Application Server Platform

By on January 19, 2010 2:25 am
This entry is part 1 of 12 in the series Server-Side JavaScript, Pintura, and Persevere 2.0

CommonJS (formerly known as ServerJS) has become the essential hub around the development of server side JavaScript (SSJS). SSJS for years has suffered from fragmentation, but the CommonJS project has provided the momentum to bring different frameworks together and start building interoperable modules. SSJS is ripe with potential; JavaScript has been soaring in popularity and the ECMAScript 5 specification was recently accepted. JavaScript has proven itself as the language of the web’s client-side (even ActionScript is a derivative of JavaScript). The opportunity to use the same language on both client and server is certainly most realistic and viable with JavaScript as it avoids the need for translation.

CommonJS

CommonJS has focused on developing critical APIs for building reusable modules, particularly for server-side JavaScript environment. The server-side is generally based around database interaction, file I/O, HTTP serving, and the generation of data formats and HTML, whereas the client-side is based around DOM manipulation and the browser object model. There are certainly APIs that can be used on both sides, and JavaScript on the client and server invites the reuse of APIs where possible. The WebWorker, Indexed Database, and XHR APIs are promising to be enormously beneficial on the server side, and with excellent client server consistency. But still the server side requires special attention, and CommonJS is bringing the needed standards and conventions.

Nodules: Better Module/Package Handling for Node.js

By on September 15, 2010 5:25 am
This entry is part 2 of 12 in the series Server-Side JavaScript, Pintura, and Persevere 2.0

Nodules is a module loader for Node that provides a powerful set of features for application development and distribution. Nodules was written to solve the two major missing pieces of functionality I needed for efficient application development: flexible dependency resolution and module reloading. Nodules runs on top of Node’s simple base module loader, and nicely compliments the base loader with additional functionality. Furthermore, it provides this functionality using idiomatic asynchronous techniques, a smart package layout, and powerful module reloading.

Introducing Pintura

By on January 22, 2010 2:43 am
This entry is part 3 of 12 in the series Server-Side JavaScript, Pintura, and Persevere 2.0

Pintura is a CommonJS/JSGI-compliant, server-side JavaScript-based framework for building rich Internet application with the REST architectural style, thin storage-oriented server design, and the consistency of end-to-end JavaScript. The Pintura framework forms the core of Persevere 2.0, and is the first framework built to run on multiple CommonJS platforms like node.js, Narwhal/Jack, and Flusspferd/Zest. It utilizes a layered approach to application development that facilitates straightforward, modular web applications.

Pintura is not a traditional MVC web server framework, which often conflate presentation and interaction concerns across the client and server, but rather follows the REST prescription of maintaining simple storage and serialization oriented server also known as thin server architecture or SOFEA. Pintura is designed to cleanly separate the concerns of presentation and interaction on the client, and storage and model logic concerns on the server. This design fits perfectly with comprehensive JavaScript frameworks like Dojo, General Interface, Cappuccino, YUI, and ExtJS that provide client-side MVC. In particular, Dojo has excellent support for standards-based JSON REST interaction that matches perfectly with this server-side framework.

Getting Started With Pintura

By on January 25, 2010 1:07 am
This entry is part 4 of 12 in the series Server-Side JavaScript, Pintura, and Persevere 2.0

Pintura is a REST-style web framework that utilizes a layered approach to application development that facilitates straightforward, well-designed rich internet applications. Pintura forms the core web framework for Persevere 2.0, and consists of a powerful data modeling and persistence framework called Perstore, in combination with a REST-style web framework. You can read more about the goals and principles behind Pintura, but here we will look at how to get started writing applications.

Pintura-based applications normally consist of server-side data models with three layers: data stores, store models, and model facets. On top of this, different representation handlers (for serializing data to different formats) can be defined, but Pintura comes with a good set of these (including JSON, JavaScript, multipart, and Atom), so usually that is not necessary. This provides a well-structured separation of concerns, distinguishing storage configuration (data stores), core data logic (models), varying capabilities of access to the data (facets), and data serialization (representations). Perhaps the easiest way to understand this approach to take a look at an example application.

Promised-IO

By on September 20, 2010 12:24 am
This entry is part 5 of 12 in the series Server-Side JavaScript, Pintura, and Persevere 2.0

Promises are a well-established mechanism for modeling future or asynchronous actions. Promises allow asynchronicity while maintaining the core programming principles of composability and encapsulation. Writing asynchronous code in JavaScript can often be a confusing exercise due to the extensive need for callbacks, but promises help to define composable units of asynchronicity to encapsulate actions and reliably separate caller and callee’s concerns.

Promised-IO

Promised-IO utilizes promises as an abstraction for I/O operations on top of Node, Narwhal/Rhino, and the browser (where possible). This serves two purposes. First, this package provides the benefits of promise usage: clean separation of concerns and proper encapsulation of eventual values. Second, Promised-IO provides a consistent normalized interface for I/O that will work on multiple platforms without sacrificing any of the advantages of asynchronous I/O, making it easy to build modules that can be used by developers on many platforms.

Patr: Promise-based Asynchronous Test Runner

By on September 21, 2010 12:01 am
This entry is part 6 of 12 in the series Server-Side JavaScript, Pintura, and Persevere 2.0

Patr (Promise-based Asynchronous Test Runner) is a simple lightweight cross-platform test runner for promised-based applications. Patr executes tests by simply executing functions of an object and is intended to be used in combination with the “assert” module (which is available on NodeJS and Narwhal), so tests can be as simple as:

var assert = require("assert");
tests = {
  testSomething: function(){
    assert.eq(3, 3);
  }
}
require("patr/runner").run(tests);

Pintura JSGI Modules

By on March 4, 2010 1:18 am
This entry is part 7 of 12 in the series Server-Side JavaScript, Pintura, and Persevere 2.0

Pintura is a REST-style web framework that provides a comprehensive solution for Ajax-based thin-server applications. However, Pintura has a very modular design, and many of the modules in Pintura are extremely useful as standalone JavaScript/CommonJS components that can be used with Node, Narwhal and other projects. Let’s look at the JSGI middleware modules. JSGI middleware modules are designed to be used in a JSGI HTTP request handling stack, adding functionality to a web application. An example of using a JSGI middleware:

exports.app = MiddleWare( // wrapped my application with middleware
  function(request){
     ... my JSGI application ...
  });

Run-Anywhere JavaScript Modules Boilerplate Code

By on September 30, 2010 4:53 am
This entry is part 8 of 12 in the series Server-Side JavaScript, Pintura, and Persevere 2.0

For developers that are creating libraries and modules, it is generally preferable to make your code available to as broad of range of users as possible. There are several different module formats in JavaScript (a module is an encapsulation of code that draws on other modules). Picking one format is often mutually exclusive to the other formats. However, in this post I want to demonstrate how you can write JavaScript modules that can be used with multiple module loaders using some simple boilerplate. Of course not all the module loaders necessarily make sense for all modules. If you are writing a module that relies on the Node file system API, it only needs it to work with the NodeJS/CommonJS module format. Likewise, a DOM-based module wouldn’t need to run on Node.

Here we’ll deal with the actual module format, the mechanism of specifying dependencies and exporting or returning functions from the module that can be used by the users. This does not deal with the normalization of the actual APIs of the underlying system, although you might want to take a look at promised-io if you would like normalization of IO interaction across the browser, Node, and Rhino/Narwhal.

CommonJS Utilities

By on March 2, 2010 10:02 am
This entry is part 9 of 12 in the series Server-Side JavaScript, Pintura, and Persevere 2.0

CommonJS Utils is a collection of general purpose CommonJS-compliant modules. These modules can be used on Narwhal, Node, and other CommonJS platforms. The modules include:

  • json-schema.js – This is a JSON Schema validator module. It can be used to validate data structures using JSON schema definitions. For example:
    var validate = require("json-schema").validate;
    var data = {name: "Test"};
    var schema = {
      properties: {
         name: {type: "string"},
         age: {type: "number"}
      }
    };
    var validation = validate(data, schema);
    validation.valid -> false
    validation.errors -> indicates that age was not provided
    data.age = 30;
    var validation = validate(data, schema);
    validation.valid -> true
    

    This module also supports using standard native constructors as type definitions. The schema above could be written
    more briefly:

    var schema = {
      properties: {
         name: String,
         age: Number
      }
    };
    

Object Capability Model and Facets in Persevere

By on March 8, 2010 12:06 am
This entry is part 10 of 12 in the series Server-Side JavaScript, Pintura, and Persevere 2.0

The object capability model is an approach to security that utilizes object references as the primary means of controlling access and providing authority. Capability-based security follows the principle of using unforgeable capabilities to provide access to resources. Object capability builds on capability-based security by leveraging object references as the primary representation of capabilities, which are naturally unforgeable in memory safe languages. Object capability based security is an elegant approach to security because the goals of object-oriented principles of encapsulation and information hiding are realized in virtually the same exact manner as the principle of least authority that is at the heart of object capability security. This type of security is extremely flexible and customizable since it is based on object-oriented design. Plus, writing good code naturally leads to secure code, security can be designed with object encapsulation hand-in-hand.