Skip to content

Instantly share code, notes, and snippets.

Thorax Server Side Rendering

WARN: This is preliminary documentation and subject to change.

There are three major concerns that need to be solved to do full server-side rendering of our current code base, server-based routing, HTML rendering and restoring views once recieved on the client.

Server Routing

Server routing is built on top of Hapi's routing stack. At build time all backbone routes are converted to Hapi routes which the Scotsman project registers on server startup. This is done through the module-map.json config file, included in the static resource bundle.

@kpdecker
kpdecker / leaky-error.js
Created April 17, 2014 00:26
V8 error stack retention
// #! node --trace-gc --expose-gc leaky-error.js
var heapdump = require('heapdump');
function Root() {
this.exec = function() {
throw new Error('test');
};
}
@kpdecker
kpdecker / backbone-start-hack.js
Created April 20, 2014 23:36
Hack for backbone router start requirement in Thorax
Backbone.history = new Backbone.History();
// Preload the root value so getFragment does not blow up prior to start being called
Backbone.history.root = '/';
@kpdecker
kpdecker / timere-test.js
Created May 14, 2014 04:13
Phantom Timer Test
// WARN: DO NOT RUN THIS. IT WILL BREAK YOUR SANITY.
console.log('Loading a web page');
var page = require('webpage').create();
page.onConsoleMessage = function(msg, lineNum, sourceId) {
console.log('CONSOLE: ' + msg + ' (from line #' + lineNum + ' in "' + sourceId + '")');
};
page.evaluateJavaScript('function() {\
window.doIt = function() {\
console.log(setTimeout(doIt, 0));\
@kpdecker
kpdecker / index.html
Created June 18, 2014 06:18
Canvas Flower
<!DOCTYPE html>
<html>
<head>
</head>
<body>
<canvas id="output" width="600" height="800"></canvas>
<script>
// Renderer code
var output = document.getElementById('output'),
@kpdecker
kpdecker / compat-mode-performance.md
Created August 14, 2014 01:54
Handlebars Compat Mode Comparison

Compat Mode

ops/msec            handlebars          compat              dust                eco                 mustache            WINNER(S)
---------------------------------------------------------------------------------------------------------------------------------
arguments           473 ±3 (7)          468 ±4 (5)          NA                  NA                  NA                  handlebars
array-each          1737 ±10 (5)        867 ±12 (3)         1172 ±7 (6)         306 ±12 (3)         349 ±6 (7)          handlebars
array-mustache      1541 ±21 (5)        847 ±8 (4)          NA                  NA                  NA                  handlebars
complex             798 ±4 (3)          284 ±2 (4)          625 ±9 (4)          209 ±8 (3)          162 ±1 (6)          handlebars
data                687 ±3 (4)          557 ±2 (4)          NA                  NA                  NA                  handlebars
depth-1             880 ±10 (5)         885 ±5 (3)          NA                  312 ±12 (4)  
@kpdecker
kpdecker / node-periodic-timers.md
Last active August 29, 2015 14:07
Node Periodic Timer Behaviors

Node Periodic Timer Behaviors

Recently had a code review where the distinction between setInterval and setTimeout under Node came up. Wanting to answer this question I put together some simple tests. The behavior of the two implementations, as of Node 0.10.30, was surprisingly reverse of my expecations, but there is a lot of nuance to how the event loop works in this case.

setInterval

setInterval's behavior is similar to what one would expect from a exec+setTimeout loop. It's period is going to be it's exec time plus the interval value.

setInterval Delay: 50 Interval: 100 Wait mode: none
/* exported Handlebars */
(function (root, factory) {
if (typeof define === 'function' && define.amd) {
define([], factory);
} else if (typeof exports === 'object') {
module.exports = factory();
} else {
root.Handlebars = root.Handlebars || factory();
}
}(this, function () {
@kpdecker
kpdecker / nodebf.md
Last active June 2, 2016 18:02
mobile.walmart.com #nodebf 2014

Mobile Server Side Rendering

This year marks the first year that we are doing full scale rendering of our SPA application on our mobile.walmart.com Node.js tier, which has provided a number of challenges that are very different from the mostly IO-bound load of our prior #nodebf.

The infrastructure outlined for last year is the same but our Home, Item and a few other pages are prerendered on the server using fruit-loops and hula-hoop to execute an optimized version of our client-side JavaScript and provide a SEO and first-load friendly version of the site.

To support the additional CPU load concerns as peak, which we hope will be unfounded or mitigated by our work, we have also taken a variety of steps to increase cache lifetimes of the pages that are being served in this manner. In order of their impact:

Event Loop Management

@kpdecker
kpdecker / resolver.diff
Created February 10, 2015 06:47
resolver.diff
diff --git a/lib/resolver.js b/lib/resolver.js
index c4cb078..0bbeec5 100644
--- a/lib/resolver.js
+++ b/lib/resolver.js
@@ -1,42 +1,15 @@
-// This implementation of the url resolver adds awareness for webpack loaders
-/*
-
-Modified from the stylus implementation:
-