|
63 | 63 | </div> |
64 | 64 |
|
65 | 65 | <div class="pipeline"> |
66 | | - <div class="pipeline-label"><span>Request lifecycle</span></div> |
| 66 | + <div class="pipeline-label"> |
| 67 | + <span>Request lifecycle</span> |
| 68 | + <span><a href="{{ url('page::architecture') }}">All 19 stages →</a></span> |
| 69 | + </div> |
67 | 70 | <div class="pipeline-track"> |
68 | 71 | <div class="pl-packet" aria-hidden="true"></div> |
69 | 72 | <div class="pl-step"><span class="name">CORS</span><span class="tag">mezzio-cors</span></div> |
|
227 | 230 | </div> |
228 | 231 | <p class="lede">Scheduled work that refuses to trample itself.</p> |
229 | 232 | <p class="desc"> |
230 | | - Console commands are registered through <code>dot-cli</code> on top of Symfony Console. The file |
231 | | - locker, enabled by default, writes a lock file per command so a second instance cannot start |
232 | | - while the previous run is still going - the safeguard cron jobs usually lack. |
| 233 | + Console commands are registered through <code>dot-cli</code> on top of Symfony Console, and |
| 234 | + <code>php ./bin/cli.php route:list</code> prints every endpoint the application exposes. The |
| 235 | + file locker, enabled by default, writes a lock file per command so a second instance cannot |
| 236 | + start while the previous run is still going - the safeguard cron jobs usually lack. |
| 237 | + </p> |
| 238 | + </div> |
| 239 | + |
| 240 | + <div class="card" style="--accent:var(--brand-red)"> |
| 241 | + <div class="card-top"> |
| 242 | + <div><span class="kicker">Operations · Mail</span><h3>Transactional email</h3></div> |
| 243 | + </div> |
| 244 | + <p class="lede">Account mail that works before you configure anything.</p> |
| 245 | + <p class="desc"> |
| 246 | + <code>dot-mail</code> wraps Symfony Mailer with templated messages, so account activation and |
| 247 | + password reset send out of a fresh install. It joins the request flow only where it is needed - |
| 248 | + the rest of the pipeline is unchanged whether a route sends mail or not. |
233 | 249 | </p> |
234 | 250 | </div> |
235 | 251 |
|
|
305 | 321 | API versions. The same codebase evolves gradually and clients are given notice, instead of every |
306 | 322 | change forking into another branch you have to keep alive. |
307 | 323 | </p> |
| 324 | + <p class="lede"> |
| 325 | + The mechanism is <code>DeprecationMiddleware</code>: mark a handler with the |
| 326 | + <code>#[ResourceDeprecation]</code> attribute and the response carries <code>sunset</code> and |
| 327 | + <code>link</code> headers, so a client learns an endpoint is retiring from the endpoint itself |
| 328 | + rather than from a changelog it never read. |
| 329 | + </p> |
308 | 330 | <p class="lede"> |
309 | 331 | Full versioning stays reserved for major, format-level changes - the cases where it genuinely earns |
310 | 332 | its maintenance cost. The two approaches are not mutually exclusive. |
311 | 333 | </p> |
312 | 334 | <div class="hero-ctas"> |
313 | 335 | <a class="btn btn-ghost" href="https://docs.dotkernel.org/api-documentation/v6/tutorials/api-evolution/" target="_blank" rel="noopener">API evolution guide</a> |
| 336 | + <a class="btn btn-ghost" href="{{ url('page::architecture') }}">Where it sits in the pipeline</a> |
314 | 337 | </div> |
315 | 338 | </div> |
316 | 339 | <div class="callout"> |
|
0 commit comments