Stability: 2 - Unstable
The API is in the process of settling, but has not yet had sufficient real-world testing to be considered stable.
Backwards-compatibility will be maintained if reasonable.
The app
directory contains logic concerned with the lifecycle of the Sails core itself. This includes:
- Loading and initializing hooks
- Loading the router
- Populating middleware library
- Teardown and cleanup of the currently-running instance of sails
The Sails core has been iterated upon several times to make it easier to maintain and extend. As a result, it has a very particular loading order, which its hooks depend on heavily. This process is summarized below.
Populate sails.config
with core (hook-agnostic) implicit defaults. Then apply the initial known set of configuration overrides, including command-line options, environment variables, and programmatic configuration (i.e. options passed to sails.load
or sails.lift
.)
The most important core implicit default configuration is the set of built-in hooks.
Load hooks in the proper order.
Grab this.middleware
from each hook and make it available on the sails
object as sails.middleware.[HOOK_ID]
.
Prepares the core Router, then emit multiple events on the sails
object informing hooks that they can safely bind routes.
After all hooks have initialized, Sails exposes global variables
(by default: sails
object, models, services, _
, and async
)
This step does not run when
sails.load()
is used programmatically. To also run the initialization step, usesails.lift()
instead.
- Start attached servers (by default: Express and Socket.io)
- Run the bootstrap function (
sails.config.bootstrap
)
- What is the difference between
sails.lift()
andsails.load()
?lift()
===load()
+initialize()
. It does everythingload()
does, plus it starts any attached servers (e.g. HTTP) and logs a picture of a boat.
If you have a question that isn't covered here, please feel free to send a PR adding it to this section (even if you don't have the answer!)