Application Lifecycle

An Express application is created as a callable function, given application and event-emitter behavior, equipped with request and response prototypes, and initialized before it is returned to the caller.

This lifecycle exists so the returned object is ready to receive requests and expose the application APIs before user code starts configuring routes or opening a server.

Sources: lib/express.js:36-56, lib/express.js:37-55

Core concepts

Application factory

The application factory builds and returns the Express application object. createApplication creates a function that forwards requests to app.handle, mixes in EventEmitter and application behavior, creates request and response prototypes, calls app.init(), and returns app.

Sources: lib/express.js:36-56

Application object

The application object is both a callable request handler and the object on which Express application behavior is exposed. The callable app delegates incoming req, res, and next values to app.handle.

Sources: lib/express.js:37-39

Default settings

Default settings are initialized during app.init(), but the provided source excerpts do not show the implementation of defaultConfiguration(). The available tests establish two observable defaults: an empty NODE_ENV produces an env setting of development, and production enables view cache.

Sources: test/app.js:90-119

HTTP server

The HTTP server is the Node server returned by app.listen(). The available tests establish that app.listen() wraps the application with an HTTP server, accepts a port and callback, accepts hostname and backlog arguments, and reports server errors through the callback.

The lifecycle moves from construction to initialization and then to a usable application object.

Sources: test/app.listen.js:6-25, test/app.listen.js:27-43, lib/express.js:36-56

What happens inside application creation

createApplication first creates the callable app; the function body calls app.handle(req, res, next), so the application itself can be passed where a request handler is expected.

It then mixes EventEmitter.prototype and proto into app, preserving the event-emitter behavior and adding the application prototype behavior shown by the factory.

Next, it creates app.request from req and app.response from res, attaching the application through each prototype’s app property.

Only after those objects are prepared does createApplication call app.init(). The factory then returns the initialized app, so initialization occurs before the caller receives the application.

The dependency declarations show that the application module supplies Router, View, finalhandler, http, and configuration compilers such as compileETag, compileQueryParser, and compileTrust; however, the supplied excerpts do not show which of these are used by app.init().

The call order inside the factory is summarized here.

Sources: lib/express.js:36-39, lib/express.js:41-43, lib/express.js:44-52, lib/express.js:54-55, lib/application.js:16, lib/application.js:18, lib/application.js:19, lib/application.js:21, lib/application.js:22, lib/application.js:23, lib/application.js:26, lib/express.js:36-55

How default settings are observed

The available evidence shows that NODE_ENV influences the application’s initial settings. When NODE_ENV is empty, creating an application results in app.get('env') returning development.

When NODE_ENV is production, creating an application results in app.enabled('view cache') being true.

The pack does not include the body of defaultConfiguration() or a complete list of settings, so it does not establish other defaults or the exact internal order by which those settings are assigned. The safe boundary is that app.init() runs during construction, and the tests verify the two environment-dependent outcomes above.

Applications can then make their own environment-sensitive decisions using the resulting setting; for example, the error-pages example disables verbose errors when app.settings.env is production.

Sources: test/app.js:106-119, test/app.js:90-104, lib/express.js:54-55, test/app.js:90-119, examples/error-pages/index.js:17-26

What app.listen() does

The tests establish the public behavior of app.listen(): it returns a server whose callback can close the server, and the server exposes an address and an assigned port after listening.

The method accepts the port and callback form, and it also accepts hostname and backlog before the callback. The test uses app.listen(0, '127.0.0.1', 5, callback) and verifies the bound address and dynamically assigned port.

With no arguments, app.listen() is treated by the test as equivalent to app.listen(0, done), and the returned server can be closed.

If another application attempts to listen on an already-used port, the callback receives an error whose code is EADDRINUSE.

The source excerpt includes the node:http dependency, but it does not include the implementation of app.listen() itself. Therefore, the evidence supports describing app.listen() as an HTTP-server wrapper with the tested argument and error behavior, but not a more detailed internal call sequence.

Typical examples call app.listen(3000) only when the module is the entry point, leaving the configured application exportable when it is imported.

Sources: test/app.listen.js:6-12, test/app.listen.js:27-35, test/app.listen.js:38-43, test/app.listen.js:14-25, lib/application.js:19, test/app.listen.js:6-25, test/app.listen.js:27-43, examples/web-service/index.js:113-117

How it connects

The application factory connects the Express entry point to application behavior through proto, and it connects request and response behavior through req and res.

Read Express Overview for where package bootstrapping begins and which entry points lead to application creation. The routing behavior used after initialization is covered by App Routing & Request Dispatch, while application settings and their public APIs are covered by App Configuration & Settings. The HTTP server’s request handling boundary leads into Routing Architecture and Built-in Middleware.

Sources: lib/express.js:18, lib/express.js:20, lib/express.js:21

Key takeaways

• createApplication constructs, mixes, initializes, and returns the callable app.
• app.init() runs before the caller receives the application.
• An empty NODE_ENV produces development; production enables view cache.
• app.listen() returns an HTTP server and supports tested port, hostname, backlog, callback, and error cases.
• The provided excerpts do not expose the bodies of defaultConfiguration() or app.listen(), so their unshown internals should not be inferred.