sails
)The Sails application object contains all relevant runtime state for a Sails application.
By default it is exposed globally as sails
, but this behavior can be disabled, e.g. for
use cases where multiple Sails app instances need to exist at once, or where globals
are not an option. The application object can also always be accessed on an incoming
request (req._sails
), and inside of model and service modules via this.sails
.
An application instance is automatically created the first time you require('sails')
.
This is what is happening in the generated app.js
file:
var sails = require('sails');
The application object has a number of methods and properties which are useful.
The officially supported methods on the sails
object are covered by the other
pages in this section. Here are a few of its most useful properties:
A dictionary of all loaded Sails models, indexed by their identity.
By default, a model's identity is the lowercased version of its filename, without the .js extension. For example, the default identity for a model loaded from api/models/PowerPuff.js
would be powerpuff
, and the model would be accessible via sails.models.powerpuff
. A model's identity can be customized by setting an identity
property in its module file.
The full set of configuration options for the Sails instance, loaded from a combination of environment variables, .sailsrc
files, user-configuration files and defaults. See the configuration concepts section for a full overview of configuring Sails, and the configuration reference for details on individual options.
A set of convenience methods for low-level interaction with connected websockets. See the sails.sockets.*
reference section for details.
A dictionary of all loaded Sails hooks, indexed by their identity. Use sails.hooks
to access properties and methods of hooks you've installed to extend Sails; for example, by calling sails.hooks.email.send()
. You can also use this dictionary to access the Sails core hooks, for advanced usage.
By default, a hook's identity is the lowercased version of its folder name, with any sails-hook-
prefix removed. For example, the default identity for a hook loaded from node_modules/sails-hook-email
would be email
, and the hook would be accessible via sails.hooks.email
. An installed hook's identity can be changed via the installedHooks
config property.
See the hooks concept documentation for more info about hooks.
sails.io
The API exposed by the sails.sockets.*
methods is flexible enough out of the box to cover the requirements of most applications, and using them will future-proof your app against possible changes in the underlying implementation. However, if you are working on bringing some legacy code from a vanilla Socket.io app into your Sails app, it can be useful to talk to Socket.io directly. To accomplish this, Sails provides raw access to the underlying socket.io server instance (io
) as sails.io
. See the Socket.io docs for more information. If you decide to use Socket.io directly, please proceed with care.
As of the final v0.12 release, Sails bundles
[email protected]
as a dependency of sails-hook-sockets, a core hook.
If you are implementing something unconventional (e.g. writing tests for Sails core)
where you need to create more than one Sails application instance in a process, you should not use
the instance returned by require('sails')
, as this can cause unexpected behavior. Instead, you should
obtain application instances by using the Sails constructor:
var Sails = require('sails').constructor;
var sails0 = new Sails();
var sails1 = new Sails();
var sails2 = new Sails();
Each app instance (sails0
, sails1
, sails2
) can be loaded/lifted separately,
using different configuration.
For more on using Sails programatically, see the conceptual overview on programatic usage in Sails.