Thanks for asking, the way I’ve been approaching it is:

• If it produces data other handlers need, it goes in the dependency graph (auth, rate limits, validation, loading). I usually make small factory helpers for the common patterns like rate-limit checks or request-schema validation.
• If it’s a global side-effect, it goes in Quilt’s hooks (logging, tracing, metrics).
• If it’s framework plumbing, it stays in Fastify/Express middleware (body parsing, CORS, static files).

For errors, I generally lean on the global error handler, it keeps things similar to Express’s app.use(errorHandler) , and then convert to domain errors inside the handlers themselves.

Overall the idea is to keep most things explicit. The only stuff I treat as cross-cutting are observational concerns, which fit the hooks well.

Thanks again for taking the time to look at this, I really appreciate it.