You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For those used to thinking of a server as a function, which Starlette's BaseHTTPMiddleware does (caveat: it has its own problems), ASGI middleware can be quite confusing for two reasons:
The mapping of ASGI concepts to HTTP request/response cycle concepts, at a level that the average dev will be aware of, is not clear (what are send and receive, and how do they relate to requests and responses?)
Many operations are made much easier by not inspecting the raw scope dict, but rather performing framework-provided transformations (e.g. litestar.datastructures.Headers.from_scope or litestar.datastructures.URL.from_scope) on scope. These transformations are not inherently discoverable.
Summary
For those used to thinking of a server as a function, which Starlette's
BaseHTTPMiddleware
does (caveat: it has its own problems), ASGI middleware can be quite confusing for two reasons:send
andreceive
, and how do they relate to requests and responses?)dict
, but rather performing framework-provided transformations (e.g.litestar.datastructures.Headers.from_scope
orlitestar.datastructures.URL.from_scope
) onscope
. These transformations are not inherently discoverable.My suggestion: add multiple examples to the creating Middleware page, like Starlette already does.
The text was updated successfully, but these errors were encountered: