App Routing & Request Dispatch
The application object is callable: invoking it with req, res, and next immediately delegates to app.handle(req, res, next).
This separates the public application function from the dispatch entry point, while createApplication attaches application behavior and initializes the returned object.
Sources: lib/express.js:37-39, lib/express.js:36-56
Core concepts
Callable application
A callable application is the function returned by createApplication, whose body forwards request arguments to app.handle.
Sources: lib/express.js:36-56
Middleware registration
Middleware registration adds functions or mounted applications to the application’s routing behavior; the shown app.use() example mounts blog below /post/:article.
Sources: test/app.use.js:71-83
Route registration
Route registration creates a route object for a path, after which methods such as .get() add handlers to that route.
Sources: test/app.route.js:42-53
Router boundary
The router boundary is the dependency represented by Router, which both lib/application.js and lib/express.js load from the external router package.
Sources: lib/application.js:26, lib/express.js:19
How an application call reaches dispatch
The call path shown by the source is short: the callable application receives the request pair and delegates to app.handle.
Evidence
- request-callerlib/express.js:37
- application-functionlib/express.js:37
- dispatch-entrylib/express.js:37
- next-callbacklib/express.js:37
The diagram’s only proven call is from the function body to app.handle; the excerpt does not show what app.handle does internally.
createApplication constructs that callable function, mixes in EventEmitter.prototype and proto, creates request and response prototypes that point back to the application, calls app.init(), and returns app. The request and response prototype setup explains how the returned application is connected to the objects used by handlers, but the supplied excerpts do not show dispatch-time mutation or router traversal.
Sources: lib/express.js:37-39, lib/express.js:36-56, lib/express.js:44-52
How registration shapes the handler set
The registration APIs shown in the evidence differ by the object they configure and by whether they create a route object.
| API | What it registers | Path behavior | Evidence |
|---|---|---|---|
app.use() | A middleware function or mounted application | The mounted application is reached below the supplied prefix | app.use('/post/:article', blog) |
app.route() | A route object for one path | The returned route can receive method-specific handlers | app.route('/:foo').get(...) |
route.all() | A handler on the route object for the route’s all-method path | Multiple route.all() handlers can participate, including error handling | route.all(function ...) |
These rows are established by the mounting, route, and route-handler excerpts.
app.use('/post/:article', blog) mounts blog under a dynamic prefix, and a request for /post/once-upon-a-time reaches the mounted application’s root handler. This is different from app.route('/:foo'), which creates a route object that can then receive a .get() handler for that path.
An empty route can exist without producing a response: the test creates app.route('/:foo') without adding a handler, then expects a request for /test to return 404. The shown evidence therefore supports a distinction between creating a route and attaching a method handler to it.
The excerpts show route.all() on the route object, including a chain where one handler rejects a promise, a second handler rejects again, and a later handler sends a 500 response. They do not show the implementation of app.all(), so this page does not infer whether its registration path is identical to route.all().
Sources: test/app.use.js:71-83, test/app.route.js:42-62, test/app.route.js:151-170, test/app.route.js:42-53, test/app.route.js:55-62
Where the application meets the router
The application module declares Router by requiring the external router package. The Express entry module also declares its own Router from that same package. This establishes the package boundary through which routing functionality is brought into the application code.
Evidence
- express-entrylib/express.js:36
- application-objectlib/express.js:37
- dispatch-entrylib/express.js:37
- router-packagelib/application.js:26
- router-packagelib/express.js:19
The exact hand-off from app.handle into the router is not visible in the supplied excerpts: no app.handle implementation or router invocation is included. The precise supported conclusion is that the application’s dispatch entry is app.handle, while Router is the named external routing dependency loaded by both relevant modules.
Sources: lib/application.js:26, lib/express.js:19, lib/express.js:37-39
How it connects
Application construction and default initialization are covered in Application Lifecycle, while application settings that can affect request behavior are covered in App Configuration & Settings. The external router’s matching, layers, and parameter behavior belong in Routing Architecture, because this page only proves the application entry point and registration examples.
Handlers operate on the request and response objects connected during application creation; their broader APIs are documented in The Request Object and Response: Sending Data. The examples of middleware and mounted routes can be compared with Examples: MVC & Route Organization.
Sources: lib/application.js:26, lib/express.js:19, lib/express.js:44-52, test/app.use.js:71-83
Key takeaways
- Calling the application function delegates directly to app.handle.
app.use()mounts middleware or an application below a path prefix.app.route()creates a route object; method handlers must be attached separately.- The evidence shows
route.all(), but not the implementation ofapp.all(). Routeris loaded from the externalrouterpackage, but the internal app.handle hand-off is not shown.