The Smart Framework separates your application into three precision-engineered layers — Frontend, Middleware, and Backend — each with a single, non-negotiable responsibility. No leakage. No overlap. No compromise.
Three layers. Crystal-clear boundaries. The middleware layer is the secret — it silently handles everything your backend used to drown in.
This is not a convention. It's structural enforcement. The framework makes it impossible for concerns to bleed across layers.
The FE layer consists of standalone, hot-swappable component units built with Smart UI Libraries. The Browser Extension provides a live dev overlay. IDE Extensions bring framework awareness directly into your editor.
The middleware layer is where Smart Framework's intelligence lives. Every request passes through a six-stage pipeline that handles authentication, authorization, Ghost Protection, and audit logging — automatically, invisibly, without a single line of code from you.
The BE layer receives requests that have already been fully validated, authorized, and sanitized by middleware. It has one job: execute business logic and return a result. That is all it will ever do.
Most authentication and authorization frameworks require you to annotate, decorate, or call a guard function. Smart Framework's Smart-Code engine reads your route definitions and the Admin Panel policy store, then automatically weaves authentication, authorization, and safety into the request pipeline. You write nothing.
Every inbound request is inspected for a valid JWT. The token is decoded, verified against the secret store, and the resulting identity principal is bound to the request context. Expired, malformed, or missing tokens terminate here with a 401. Your backend code never sees an unauthenticated request.
The Smart-Code engine queries the Admin Control Panel policy store for the current route + HTTP method combination. If the identity principal lacks the required permission, a 403 is returned immediately. Policies are evaluated in real time — no deployment required to update them. No decorator. No guard annotation in your code.
For write operations, the request body is scanned field-by-field (and recursively into nested objects) against the field-level policy for this principal. Fields the user is not permitted to write are silently stripped from the payload before it ever reaches your backend handler. For reads, the response body is filtered on egress by the same mechanism.
Once auth policies are enforced, the authenticated, field-filtered request is passed clean to the BE library. Ghost Record Protection is not a Middleware concern — it is a native capability built into the Smart Framework's FE and BE libraries. The FE library tracks field-level fetch snapshots on the client side; the BE library validates incoming writes against concurrent modifications and resolves conflicts at the field level before any data is persisted. Both layers operate automatically with zero developer code required.
After the handler executes, the middleware captures the response, computes a precise before/after field-level diff, and writes it to the audit store with the principal identity, timestamp, session ID, and route. Full, searchable, tamper-evident audit trail — zero code in your handlers, zero configuration per endpoint.
On the response path, the same field-level policy engine runs in reverse. Any response fields the current principal is not permitted to read are stripped before the response is serialized and returned. This applies to deeply nested structures — no manual projection needed in your query code.
Side-by-side: a real mutation handler in a traditional Node.js/Express stack versus the same handler in Smart Framework. Same business outcome. Radically different signal-to-noise.
Auth is not a library you call — it's a layer you can't skip. Every request passes through the same pipeline regardless of which handler runs. A developer cannot accidentally skip auth on a new endpoint because the framework never gives them a chance to write it.
Backend code reads exactly like a domain model: entities, operations, and rules. No cross-cutting concerns. This isn't enforced by convention or code review — it's enforced by the framework making it structurally impossible to add auth code to a BE handler.
New route added by a dev at 2pm. PM wants to restrict a field for junior users at 2:05pm. Admin updates the policy in the Control Panel. Done. No pull request. No review cycle. No deployment pipeline. Effective immediately.
A handler that contains only business logic is trivially unit-testable. No mocking of auth middleware, no JWT fixtures, no permission stubs. Pass input, assert output. Test coverage for your actual logic goes from painful to effortless.