Architecture

Architecture Overview

Netpress keeps the backend flow simple:

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

That sequence is the core mental model of the framework.

Request Lifecycle At A Glance

The router matches the incoming request.
Middleware handles cross-cutting concerns like auth, validation, throttling, and request shaping.
The controller receives the request and delegates work.
A service performs business logic or coordinates models and external systems.
Netpress turns the returned value into a response.

This keeps responsibilities separated and code easier to test.

Service Container

The service container holds shared application services behind stable keys.

Use it for things like:

mail transports
queue runtimes
cache drivers
payment clients
custom infrastructure services

Bindings can be eager values or lazy factories. That means you can define a service at boot time without actually creating it until the application needs it.

Providers And Lazy Loading

Providers are the framework boot layer.

Each provider can:

register container bindings
load config
attach middleware
mount routes
defer heavier setup until first use

This is how Netpress stays modular. Mail, queue, storage, and other optional systems do not need to boot during every request if the app is not using them yet.

Separation Of Concerns

Layer	Responsibility
Router	Match the request to an action
Middleware	Cross-cutting HTTP concerns
Controller	HTTP boundary and orchestration
Service	Business logic and workflows
Model	Data access and persistence
Provider	Application bootstrapping and infrastructure wiring

Why This Structure Works

It is easy to explain to new developers.
It scales better than “everything in routes”.
It stays flexible because each layer is still plain JavaScript.
It is friendly to AI tooling because naming and flow stay consistent.

For the lower-level flow, see Request Lifecycle. For bootstrapping details, see Providers and Service Container.