adamrenklint/asimovjs.org

View on GitHub
old/_02-the-server-application/page.txt

Summary

Maintainability
Test Coverage
title: The server application
---
text:

## TODO: change this to "the queue and the server": simplify, and describe only the essentials of both...
## cut almost everything here, mostly bullshit and not relevant for the average user, yet

At the heart of asimov.js is a simple express server with some smart middleware hooked into it. By adding your own custom initializers and request middleware, you can extend the server modify the entire flow of rendering and caching.

## Bootstrap

Once you start the server application using <code>node main.js</code>, there's a series of synchronous and asynchronous events triggering. In <code>main.js</code> you have the chance to pass in options to the bootstrap, and change the behavior of some or all components and the bootstrap process.

After playing the intro animation, the crawler scans the <code>content</code> folder for all <code>.txt</code> content textfiles and creates a map of the available urls. This map is passed to the render queue, and to the server to be used by middleware. The server then starts handling incoming requests.

Templates and template helpers are then loaded and validated, and the render queue starts processing jobs, saving its output to the in-memory cache. As application bundles and stylesheets are included in the rendered pages, they are also added to the render queue, processed and cached.

Finally, the file structure is observed for changes, which triggers re-rendering of the changed resource, and all other resources that depends on it.

## The flow of a request

When the server receives a request, it first passes through a set of server middleware, then any custom middleware you define, then some more framework middleware, and if the request has not been taken care of by then, a 404 is returned.

When a request for a url that should be cached is received, it's passed on to the cache instance that tries to find the resource. If it or any of its dependencies are in queue to be rendered, they get pushed to the front of the queue and the requests are served as soon as rendering is complete.

When the <code>ENV</code> flag is set to <code>dev</code>, **pages are always re-rendered** before they are sent to the browser - but application bundles and stylesheets are still only recompiled when changed.

## Logging (WIP)

Logging happens on three levels: verbose, default and silent. Set <code>options.logVerbose</code> to <code>true</code> in <code>main.js</code> to see everything. Set <code>options.logSilent</code> to <code>true</code> to mute all logging except for critical system messages, and of course errors.

Logging can also be done in two ways. The default style uses a hack to clear the console to change its content and update the timings and is nice and good in development. But that style of logging doesn't work well with production logs. Switch to the alternative style by by setting <code>options.devLogger</code> to <code>false</code> in <code>main.js</code>. This is done automatically when the server is started with <code>ENV=production node main.js</code>.

## Disable intro animation (WIP)

In case you want to shave of a second or two from the startup time, you can disable the intro animation by setting <code>options.animateIntro</code> to <code>false</code> in <code>main.js</code>.