thywill
Version:
A Node.js clustered framework for single page web applications based on asynchronous messaging.
214 lines (204 loc) • 8.69 kB
JavaScript
/**
* @fileOverview
* A baseline configuration file for Thywill.
*
* This is used by test code, and as an example for application configuration.
*/
//-----------------------------------------------------------
// Exports - Configuration
//-----------------------------------------------------------
/**
* Thywill core configuration is a nested set of objects, one for each
* of the core components. The configuration specifies which component
* implementations to use, and provides their specific configuration
* parameters.
*
* Note that Thywill applications are not configured this way, but are
* expected to use their own configuration methodology.
*
* Note that everything in this base configuration object should be clonable -
* so no class instances, etc. Those should be created and set in the start
* script, and are left null here.
*/
module.exports = {
// Parameters for the main Thywill wrapper, such as port to listen on,
// and configuration for the administrative interface.
thywill: {
process: {
// Group ID and User ID for the Thywill process to downgrade to
// once launched - this allows for such things as launching as
// root to bind to privileged ports, then running later as a lesser
// user.
//
// Not used on Windows, of course.
//
// Note that if you set either of these to a numeric uid, it must be a
// number not a numeric string - 312, not '312'.
groupId: 'node',
userId: 'node'
}
},
// The cache manager in an interface for creating and managing (usually
// in-memory) caches.
cacheManager: {
// Here we specify the use of the core LRU implementation.
implementation: {
type: 'core',
name: 'lruCacheManager'
}
},
// The client interface component manages communication between web browser
// and server, and thus will usually have a fairly large set of configuration
// parameters.
clientInterface: {
// Here we specify the use of the core Socket.IO implementation of this
// component.
implementation: {
type: 'core',
name: 'socketIoClientInterface'
},
// The base path is prepended to all URLs generated by the client
// interface, allowing distinction between different Thywill Node.js
// services running as backends on the same server.
baseClientPath: '/application',
// If true, minify and merge bootstrap CSS into a single resource. This is
// the CSS initially loaded when a client connections.
minifyCss: false,
// If true, minify and merge bootstrap Javascript into a single resource.
// This is the Javascript initially loaded when a client connections.
minifyJavascript: false,
// A namespace to apply to Socket.IO communications, allowing other
// Socket.IO applications to run on the same server in their own, separate
// namespaces.
namespace: '/applicationNamespace',
// The HTML page encoding to use.
pageEncoding: 'utf-8',
// The http.Server is set here.
server: {
// An http.Server instance.
server: null
},
// Configuration to apply to the Socket.IO client on setup. This is
// used as-is. See:
// https://github.com/LearnBoost/Socket.IO/wiki/Configuring-Socket.IO
socketClientConfig: {
'max reconnection attempts': 50,
// This MUST match the value of the socketConfig.*.resource value, but
// with the leading / dropped.
'resource': 'application/socket.io'
},
// Configuration to apply to the Socket.IO server setup. Both the global
// configuration and any environment-specific configurations are applied.
// Socket.IO will only use environment-specific parameters if the
// environment name matches the NODE_ENV environment variable. See:
// https://github.com/LearnBoost/Socket.IO/wiki/Configuring-Socket.IO
socketConfig: {
// Global Socket.IO configuration, will apply unless overruled by a
// environment-specific value.
global: {
'browser client minification': true,
'browser client etag': true,
// A comparatively low level of logging. If trying to debug whether or
// not websockets are working at all, setting log level to 3 is
// helpful.
'log level': 1,
// Match origin protocol MUST be true - when Node.js is operating
// behind an SSL proxy, which is the default Thywill setup, the
// difference between ws: and wss: websocket protocols becomes
// important. This ensures that Socket.IO does the right thing.
'match origin protocol': true,
// This MUST match the value of the socketClientConfig.resource value,
// but with the addition of a leading /.
'resource': '/application/socket.io',
// If using multiple Node.js processes and process A will need to send
// messages to connections on process B, then this must be a RedisStore
// and usePubSubForSending must be true. Otherwise, use a MemoryStore.
//
// This should be set in the start script.
'store': null,
// The transports to use. We're trying to be modern here and stick with
// websockets only. This means some browsers will fail miserably - so
// adjust as needed for your circumstance.
'transports': ['websocket']
},
// If NODE_ENV = production, then values set here will override the
// global configuration.
production: {
'log level': 0
}
},
// Other text file encodings, such as when loading resources from the file
// system.
textEncoding: 'utf-8',
// The path for a page to be called by proxy and monitoring up checks.
upCheckClientPath: '/alive',
// If you have set up an application with multiple Node.js processes in the
// backend, then each individual connection socket will only exist in one
// of the processes. Your application may be structured in a way that
// requires process A to send a message to a socket connected to process B.
// If this is the case, you must set usePubSubForSending to true, and
// provide a RedisStore to the socketConfig.store configuration parameter.
usePubSubForSending: false
},
// Interface for communicating between clustered Thywill server processes.
cluster: {
// This is the stub cluster communication interface for a single process
// setup - i.e. there is no cluster.
implementation: {
type: 'core',
name: 'noCluster'
},
localClusterMemberId: 'noCluster'
},
// This core component provides an interface for logging.
log: {
// We specify the simple console log implementation, which emits log
// messages via console.log(). Since a Thywill process will run as a
// service and direct stdout to a log file, this is usually just fine.
implementation: {
type: 'core',
name: 'consoleLog'
},
// The date format used in the log output.
dateFormat: 'ddd mmm dS yyyy HH:MM:ss Z',
// The minimum log level to be logged by this implementation. Lesser log
// levels are ignored. The log levels are, in order, [debug, warn, error].
level: 'debug'
},
// The minifer component manages minification and merging of CSS and
// Javascript resources that are assembled by Thywill.
minifier: {
// The ugly implementation cobbles together Uglify.js and CleanCSS
// for minification. It is, in fact, pretty ugly.
implementation: {
type: 'core',
name: 'uglyMinifier'
},
// The base path to use when defining a new resource for merged CSS.
cssBaseClientPath: '/application/css',
// The base path to use when defining a new resource for merged Javascript.
jsBaseClientPath: '/application/js'
},
// The resource manager is, as you might expect, the factory for creating and
// keeping track of resources - the CSS, Javascript, HTML, and so forth, that
// is delivered to the client.
resourceManager: {
// Here we specify a very trivial resource manager implementation that
// does little more than keep track of resources in memory.
implementation: {
type: 'core',
name: 'inMemoryResourceManager'
}
},
// The template component provides an interface to a templating engine,
// always useful when slinging around HTML and Javascript.
templateEngine: {
// Specify the Handlebars templating engine implementation.
implementation: {
type: 'core',
name: 'handlebarsTemplateEngine'
},
// The maximum number of compiled templates to retain in an LRU cache.
templateCacheLength: 100
}
};