JavaScript Module Server

Loading JavaScript

HTML

Inline scripting

Quick sandboxing
Small demos
Learning
Testing

If someone starts learning to build webpages, i'm sure inline scripting will come handy
In fact inline scripts still can have some role in the web today.
embedding, sandboxing, small distributable demos, learning, trying out new things.
more downsides than benefits, they affect pageload times,
block script execution,
and document markup is usually tied together with the scipts,
preventing the code to be reusable elsewhere.
If you keep developing this way, the code will get harder to maintain

HTML

JavaScript files

Separate code from markup
Step toward modules
Serve JS as an asset

HTML

Code organization

Functions, Classes, Modules
Codebase growth
Loading becomes an issue

As your web application gets more complex, you get used to more sophisticated code organization techniques.
You build functions, classes, components, modules, bound together or decoupled from each other
The codebase grows and grows, as you do frameworks, controllers, models, views, and loading all that code starts to be a problem

Your network connection might be broadband, but in case of loading lots of files from the internet, network latency will hold you back.
Latency is the amount of time it takes for a server recevie your request, it relates to the distance between you, and the contacted server. In case of a few files, latency is almost irrelevant.
But if you have a large codebase, contacting the servers for those files, takes time, even if your browser supports 6 or more concurrent connections
With a quick calculation, using 120 files with a browser, that supports 6 concurrent connections per host, it's going to download in 20 subsequent reguests to that host, at an average latency of 80 ms, it is going to sum up to 1.6 seconds.
1.6 seconds, while your app is doing absoultely nothing, just telling the server the files to download. This is latency.
Your app has to load it's code, the latency of loading all those files sums up, and deteriorates user experience.

Packaging JavaScript

HTML

PACKAGE

Packages

Single file
Less HTTP requests
Compressing

The lag, caused by a lot of http requests, lowers
Packaging introduces some kind of a deployment strategy
Your nicely separated and organized codebase has to be packed in a file, you can compress it, or ran it through taskrunners during deploy
Code developed locally and deployed to production become two separated worlds, debugging them requires additional tools, or modified deployment processes
But if a single line is changed in the code, the whole deployed package gets deprecated, and the client has load it again.

PACKAGE

Partitioned Packages

Packs for Features
Few more HTTP rqs
JS packs according to features

PACKAGE

modules/Foo

modules/Lorem

modules/Bar

modules/Foo

modules/Bar

modules/Ipsum

Overlapping Dependencies

common components
redundant code

PACKAGE

modules/Foo

modules/Lorem

modules/Bar

modules/Foo

modules/Bar

modules/Ipsum

modules/Baz

modules/Qux

modules/Dolor

modules/Sit

"Common Pitfall"

Put common code in a common package

Slowly leads to one,
huge package

Handling Dependencies

Modules

CommonJS

AMD

Harmony

Several Module formats can help you with this, lets take the three most promising, CommonJS, AMD and ECMAScript Harmony modules

CommonJS modules are widely considered as a module system for the server, for example nodejs uses CommonJS modules. Originally the CJS format only allowed one module per file, which makes it harder to use them in packages, together with other modules, which is clearly our goal here.

Some day Harmony modules might be the standard module format of Javascript, They are really promising, they even propose a Loader API to access remote modules, but Harmony or EcmaScript version 6 is still under development.

The features that AMD modules provide, may take us closest to our goal. AMD evolved out of the js framework called Dojo, and relies on their experience with AJAX and async loading in the browser. They are designed to be the modules for the client side.

Asynchronous Module Definition

define( 'name' , [ 'dep1', 'dep2' ] , function (dep1, dep2) { ... } );

Module Loaders

Register

Connect

Fetch

requirejs, curljs

Asynchronous Loading

SERVER

CLIENT

Async Module Loading

Require
Fetch Modules
AMD references dependencies
Wait for deps
Module available

Dependency Graph

Codebase defined
Not Feature deined

Downside

Transitive dependencies
Waterfall of requests

Async Packages

SERVER

CLIENT

PACKAGE

Async Packages

Require
Fetch Package
Module available

SERVER

CLIENT

? PACKAGE

Downside

Which package?

Walking in circles?

Negative Loading

JSConf EU 2012

Malte Ubl & John Hjelmstad

Google / GMail

First Request

Module Request
Pack all dependencies
Serve
Register requested modules

SERVER

HTML

+ mod/Foo

+mod/Bar-mod/Foo

mod/Foo

dep1

dep2

dep3

dep4

PACKAGE

SERVER

HTML

+ mod/Foo

+ mod/Bar - mod/Foo

mod/Foo

dep1

dep2

dep3

dep4

mod/Bar

dep1

dep5

dep3

dep6

Subsequent Requests

Require
Find dependencies
Subtract
Serve
Register requested modules

On the next request the client sends the requested module name, and the list of all those modules that have been requested so far

In the url, the requested modules are prefixed with a plus sign as it is an addition, they are the included modules

The modules, that have been already requested are prefixed with a subtraction sign, - thus the name "negative loading" - and they are the excluded modules.

the server collects all the transitive dependencies of the included modules
but also collects all the transitive dependencies of the excluded modules

Then it simply subtracts all the excluded modules, from the included modules, and only the delta will be packed and served.
This way only those modules are served that are not at the client, and it does this asynchronously
All requested modules are registered, for further requests, to keep their dependencies from downloading again

Dependency Handling
on the Server

JavaScript is not a static asset anymore

From now on we cant just say that javascript is a static asset, the dependency handling is done at the server side by every request

Last year I talked to one of these guys, about their solution and he kind of admitted, that some of their ideas and solutions that get out of google, are deliberately not made into an existing open sourced product, simply because they dont have the time to maintain it for others

so they spred the idea and wait for someone to grab onto it
as we were stuck with this whole problem at that time, we were happy to start to work on some more general and open sourced solution, using negative loading

JavaScript Module Server

Designed for

Single Page Applications
Large JS codebase
UX matters
Long visitor session

JMS

AMD module server for JavaScript

Serve Async and Efficiently

Deployment framework

JMS

Developed in Node.js

Stores data in Redis

Stateless server architecture

How it works

JMS

HTML

CLIENT

This is how it works

The codebase you want to serve is deployed and stored in Redis
JMS serves it's own client, which handles requests

with every request, JMS goes back to Redis for version numbers or modules

JMS calculates the package to be served by making diffs on the dependency graphs and serves the package to the client

I would like to talk about five interesting aspects of JMS the client loader deploying to JMS caching scaling and a plugin system, we've developed for it

The JMS client

JMS

HTML

JMSC

PACKAGE

+apps/Foo

+apps/Bar-apps/Foo

JMS Client

Serve client
Handle AMD
Fetch
Register
Order

Redundant requests

Circular dependencies

If your code requires a module, that have been already downloaded, the module loader resolves that request without fetching it again. Since JMS pack transitive dependencies for modules, the already downloaded module will have all it's depencies available.

JMS handles circular dependencies during packaging, and serves those modules, but AMD itself does not protect you from such anomalies.

Circular dependencies are rare issues, and usually mean that your code needs restructuring, but in some cases if they are needed, the loader has the tools to help you resolve situations like this.

JMS

HTML

JMSC v42

v42

v43

Version Handling

Cliend Init
Bound to Version
Deploy
Client keeps version

What happens when we deploy a new version of the codebase?
The client initializes with the current version of the codebase, in fact it's bound to that version. Every asynchronous module request after this pageload will address the same version
If a new version is deployed on the JMS, and becomes the latest version the client keeps using the old one, until the client is fetched again in a page load
The JMS can serve a number of old versions, this number is configurable by your needs
This way we avoid the problem of collindig different versions of the same codebase.

Client embed

...

The JMS client

Almond.js + JMS loader

Deploy

Code check
Dependencies
Plugins

Currently JMS uses Redis for this it's data management, because of two reasons

First, the asynchronous evented I/O that Node use, performs poorly when reading from disks, and we did not want to have a slower solution than our current one

Second, we could store the data simply in the memory of JMS, but then it would be more complicated to scale it properly

If you're not familiar with Redis, its an open source fast and advanced key-value storage, that aims high performance by working with an in-memory dataset. That dataset gets persistent, by dumping it to disk every once in a while, but serving data is done from memory.

To keep serving modules fast, it's best to do the CPU heavy processing tasks at deploy time.

During deploy the code gets a basic error checking. JMS has to extract the dependencies from the codebase, so it runs through the modules using a tool, called Esprima.

Esprima is an ECMAscript parser, that can create an abstract source tree from the javascript modules. Traversing through this source tree, we can easily find the dependencies for the modules. If the code has some fundamental error, Esprima cannot parse it, and returns error. This way it prevents malfunctioning code to get into production.

Using Esprima, JMS creates a dependency graph of the modules, and runs any other task we want, with the help of the plugins

Versioning

Error handling

Task runners

Cache

Unique URLs

version / + modules - modules ? extra-params

This is actually really bad

JMS currently serves javascript modules with a unique url

Every given url will give back the delta of the required and excluded module dependencies from a codebase version

Extra parameters can be passed along the request, for example a locale, they should not break this behaviour

This is actually the biggest weakness of the current version of JMS, as unique urls for modules that have not benn modified within a version deploy, still get a new url as a new cache key.
Fixing and imprioving this, is currently on the top of our todo list.

Support Re-Validation

Internal Cache
(mostly to save CPU)

JMS Support content re-validation by correctly handling the If-Modified-Since header

This means that the client or caching server can ask JMS about a cached module, if it can be used, or there is a new version available since a timestamp - passed in by the If-Modified-Since header.

The JMS either tells the client that yes, the content it has, is still fresh (http status 304) or it can send a more fresh version of the requested modules, telling the client it’s new date of creation.

it also has an internal cache for previously served urls, but that is mostly to save CPU time on the clusters

Scale

VARNISH

CDN

JMS

Plugins

Deploy

Serve

Deploy Plugins

Access all the codebase,
do the heavy work

jslint / jshint
code compression
transpile/generate

During deploy all the modules in the codebase are ran through the deploy plugins, your plugin has access the whole codebase, and can do some heavy work on them

As i've mentioned before, we've put the cpu intensive work to the deploy processes, so for the plugins, we suggest the same

Some of the possibilites are running code checks with jslint or hint, or any tool that you prefer.

Or doing code compression - actually this is a default plugin using uglify

Or transpile, or genereate EcmaScript 5 compatible javascript code from the language or javascript version you prefer

Server Plugins

Access the client request

Modify the modules to be served

i18n

Order plugins, can rely on each other

Plugin development

Simple Node.js Streams v2 interface

Every plugin is a Transform stream

Interface + Flow Control

Monitoring

Processes,
concurrent requests,
requests per second
...

Use

Integration

Measurements

Codebase refactor

Now, about using jms

It's in a really early stage,
we are currently integrating it in our systems

During this process we will run several stress tests using both emulated and real traffic, and prepare JMS for production usage

Early measurements show an instant 10-20 percent save in the sizes of served packages, compared to our current feature based and common packages, and we havent even touched the source code - beside the AMD modularization
For JMS to be optimal, we will separate our code, even more, into small standalone apps or features, that can be layered on each other, and we can load them asynchronously, one by one, if the app or some user interaction requires them

With these refactorings we predict some 30-40 percent save on scripts loaded on initial pageload

Lessons learned

npm mirror

Sinopia

https://github.com/rlidwka/sinopia

With the integration with our systems, the issue of npm downtime came up.

For nodejs modules NPM is the common module ecosystem - npm stands for "node packaged modules"
It is a global module registry free of use, but sometimes there is a downtime for some reason.
Such a downtime could affect upgrading the JMS cluster itself, if npm is unavailable at that time.

Our devops team insisted to prepare for an incidental npm outage, so we had to set up an npm mirror for ourselves.

Since npm has over a 100 gigabytes in size, we didn't want to mirror the whole repository,
so we've chosen a caching npm solution - Sinopia.
As Sinopia is a private/caching npm repository server,
in addition to our cache of used npm modules, we can internally publish and use some of our own libraries in our systems.

PM2 clustering

PM2

https://github.com/unitech/pm2

Node.js Streams

Codebase modularization

Future

GZip

Source Maps

Cache Strategies

AMD plugins

CSS

SPDY / HTTP2

ES6 modules

We will develop JMS in the future, further along

some quick low hanging fruits are: gzip compression, and addig sourcemaps for debugging

as i've mentioned before, we plan to refine the cache strategies, to be more effective

AMD modules themselves can have plugins, supporting templates, or setting extra, module specific directives for JMS during deploy, and more, we plan to handle them as well

If all this works with Javascript, why not serve CSS with JMS as well, we plan to pack and serve the css and the js code for a component together

HTTP2 or SPDY is getting more and more well deserved attention for fixing many issues with page loading, and JMS certainly will benefit from the new protocol using server side push and parallel data streams

We plan to to support ES6 Harmony modules in the near future, since they supposed to be the de facto standard modules in javascript.
On the other hand, right now, we're not thinking about supporting CommonJS, as they need some extra transportation format to pack them together.

github.com/ustream/jms

Thank you!

@_Nec

JavaScript Module Server @_Nec Szabolcs Szabolcsi-Tóth

JavaScript Module Server

Loading JavaScript

Inline scripting

JavaScript files

Code organization

Packaging JavaScript

Packages

Partitioned Packages

Overlapping Dependencies

"Common Pitfall"

Handling Dependencies

Modules

CommonJS

AMD

Harmony

Asynchronous Module Definition

Module Loaders

Register

Connect

Fetch

Asynchronous Loading

Async Module Loading

Dependency Graph

Downside

Async Packages

Async Packages

Downside

Walking in circles?

Negative Loading

JSConf EU 2012

Malte Ubl & John Hjelmstad

First Request

Subsequent Requests

Dependency Handlingon the Server

JavaScript is not a static asset anymore

JavaScript Module Server

Designed for

JMS

JMS

How it works

The JMS client

JMS Client

Redundant requests

Circular dependencies

Version Handling

Client embed

The JMS client

Almond.js + JMS loader

Deploy

Deploy

Versioning

Error handling

Task runners

Cache

Unique URLs

Support Re-Validation

Internal Cache (mostly to save CPU)

Scale

Scale

Plugins

Plugins

Deploy

Serve

Deploy Plugins

Server Plugins

Plugin development

Monitoring

Use

Lessons learned

npm mirror

PM2 clustering

Node.js Streams

Codebase modularization

Future

GZip

Source Maps

Cache Strategies

AMD plugins

CSS

SPDY / HTTP2

Dependency Handling
on the Server

Internal Cache
(mostly to save CPU)