Architecture

Request Lifecycle

Netpress keeps the request path easy to follow:

Request -> Router -> Middleware -> Controller -> Service -> Response

That is the core execution model of the framework.

Lifecycle Order

The server boots the Netpress application and loads providers.
The router matches the incoming request.
Route and global middleware run.
The controller action executes.
The controller calls services, models, or framework features.
Netpress turns the returned value into the final HTTP response.
If anything throws, the exception handler formats the error response.

Provider Boot Comes First

Before requests start flowing, providers prepare the app:

AppServiceProvider wires shared middleware and response helpers
DatabaseServiceProvider registers the database runtime
AuthServiceProvider registers guards and auth integrations
deferred providers like mail and queue stay cheap until first use
RouteServiceProvider mounts the route tree

This makes boot order explicit instead of hidden in scattered startup files.

Smart Response Dispatch

A route handler can return different kinds of values:

object or array -> JSON
string -> text response
json(...) -> explicit JSON response
view(...) -> rendered view
redirect(...) -> redirect response
null or undefined -> 204 No Content

Manual res.json() and res.send() still work when you want full control.

Why The Lifecycle Matters

This structure keeps framework behavior predictable:

middleware owns request-wide concerns
controllers own HTTP orchestration
services own business logic
providers own application bootstrapping

That separation is what makes Netpress feel structured without feeling heavy.

For the higher-level mental model, see Architecture Overview.