jonnifyelixir
F6 · Phoenix Framework / F6.01 · lifecycle

F6 · the architecture · module 1

Architecture & the request lifecycle

The path, at a glance Three deep dives

Phoenix is, at heart, one long function from a request to a response — a stack of small plugs that each take a connection and hand back a connection. A request enters at the Endpoint, the router matches it to a controller through a pipeline, the controller does the one piece of real work — it calls the Portal facade from F5 — and a view renders the result. Understanding that path is the whole of this module, because every later module plugs a capability into it: routing shapes the match, Ecto and contexts sit behind the facade, HEEx and LiveView own the render. Learn the lifecycle once and the rest of F6 is filling in stages.

This module maps the path a request travels and the one point where your code meets the engine: the request lifecycle end to end, the endpoint as a supervised process, and the controller/view seam.

One request, four stages

request Endpoint plug stack Router match + pipeline Controller calls Portal facade View renders response response

Endpoint — the request enters the plug stack.
The controller is the one stage that calls the Portal facade.

The path, at a glance

Four stages carry every request: the endpoint, the router, the controller, and the view. Three of them are framework plumbing you configure once; the fourth, the controller action, is where the Portal facade is called and the only stage that knows anything about the domain. Select a stage to see what it does and which module builds it out.

The request lifecycle · select a stage

Endpoint plug stack Router match + pipeline Controller calls Portal facade View renders result three stages are framework plumbing; the controller is the one that calls the engine

stage: Controller

does: calls the Portal facade

You are not learning four unrelated things; you are learning one pipeline. The endpoint, router, and view are configured once and rarely touched again — the controller is where you work, and all it does is call the facade and choose how to render the answer.

Three deep dives

In order: the lifecycle end to end, from the connection to the response; the endpoint as both the outermost plug and a supervised process in the F5 tree; and the controller/view seam, where your code calls only the Portal facade.

F6.01.1
The request lifecycle
A request from the browser to the response: endpoint → router → controller → view, with one call to Portal in the middle.
F6.01.2
The endpoint, supervised
The outermost plug — static, parsers, session — and a child of the OTP tree the F5.09 lab assembled. Where HTTP meets OTP.
F6.01.3
Controllers, views & the facade seam
A thin controller calls only Portal, branches on %Portal.Error{}, and picks a view; the view renders assigns.

F5 · a headless engine

F5 left a supervised facade — correct and tested, but with no way for a browser to reach it.

F6.01 · a way in

The lifecycle is the path from a URL to a facade call. Once it runs, the platform has a front door.

Start with the request lifecycle, then the endpoint, then the controller and view seam. The next module, F6.02 — Routing, controllers & plugs, builds out the match in the middle. See also the design brief: wiring Phoenix onto the F5 engine.

References

The request lifecycle, the plug abstraction it is built from, and the endpoint at its head.

Sources

Related in this course