Send static files to clients with patch files like what!
Switch branches/tags
Nothing to show
Pull request Compare This branch is 3 commits ahead, 4 commits behind DynoSRC:master.
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.

Stories in Ready


DynoSRC is a general solution for efficiently delivering JS resources to clients, using diff-based updates as assets change over time.


Minimize HTTP Requests

DynoSRC loads JavaScript files inline in your HTML response, then stores them in localStorage. You can even inline the calls to the DynoSRC client lib in your HTML response, eliminating all HTTP requests for JavaScript on your site.

Differential Updates

Normally, if a JS asset on your site changes, your users will have to download the entire file again even though just a fraction of it changed. DynoSRC sends down differentials updates so changes to large files don't require full downloads.

Getting Started

Install DynoSrc

npm install dynosrc

Configure Middleware

  //folder containing your JS / CSS files
  assetsDir: __dirname + '/assets'

//install express style middleware

  //point directly to files on github
  'ryanstevens/ModelFlow': {
    filename: 'package.json',
    source: 'git',
    //this can also be a tag
    head: '8050f1'
  'jquery': {
    head: '1.9.1',
    //this lives on disk
    source: 'asset'

Get Patches, Send to Client

app.get('/', function (req, res) {
  dynSrc.getPatches(req, {
    patches: ['jquery', 'backbone']
  }, function(err, patches) {
    res.render('index.html', {
      title: 'Super Cool Project',
      patches: patches
This will produce corresponding "patch" deltas in your HTML
//inserted from dynSrc.getPatches
dynoSrc.apply('my-cool-module', '0.1.2', '...diff...');

How does it work?

  • git diff
    • We are relying on forking out to a child_process.
    • This means the process you are running node with must have access to git.
    • The reason we are not using js-git for this was because that feature was not implemented yet.
  • DEV mode FTW
    • dynoSrc eats its own dog food in while developing. We really felt this was an important feature so this isn't just a build tool for "production". This way any bugs that come from using this strategy will appear earlier in the dev cycle, rather than in production. Here is a simple run down of what the middleware will do on every page load.
      • Look at the resources in your cookie
      • Look at every local resource in your repo that needs to be served
      • Determine if there were changes (due to direct file change via a human, or maybe grunt rewrote them)
      • Write the changed file to a scratch area with an epoc timestamp
      • Compute a diff from the last page load
      • Send ONLY the diff


  • DEV mode WILL eat your entire HD. Someone needs to write a thing to clean up all the things :)
  • Move sever oriented unit tests out of NodeKnockout repo and into public dynoSrc repo.
  • Remove hard dependancy on shelling out to git.
  • Much of this feels like it could be complimented with a Grunt task.
  • Write client unit tests against dynoSrc.js ;)
  • Bit mask resources in cookie to not store entire resource name