Meta-comment on #1519: middleware as Stream Processing

[erewok]

@tomchristie Your second example in this response reminds me of a pattern that appears often in functional programming or stream processing: map, filter, reduce, etc. I was thinking it could be a useful abstraction for something like Starlette to encourage in its middleware examples because when you think in these ways as a developer you are precluded from trying to operate on a "whole thing". (This is what I commented on as the problem in the BaseHttpMiddleware class: it encourages developers to think they're getting a complete Request or Response and this confuses things like Background.)

Following this idea, one thing that Starlette could offer is a RequestMapper class, which is like a map over a Request, to produce something like an RequestA -> RequestB before that request instance gets passed to a handler.

Expanding on that, Starlette could offer map, filter, or reduce abstractions over any of the following:

• Request
• Response,
• Request -> Response.

The "cache the whole body in memory" is maybe a fold/reduce operation in this scenario. The goal here is not to solve everyone's problems with existing middleware but to shape their expectations about what they should be able to write using middleware.

Background, of course, makes all of these things more complicated.

[erewok]

For a contrasting viewpoint, because of the ways that requests are integrated into Starlette's Router, this type of "Middleware" that I'm imagining would have to be applied differently, I think, than others, which doesn't sound so great to me. In addition, in my own projects if I wanted to map over any of these things, I'd probably use a decorator instead of middleware. Lastly, one thing I appreciate about Starlette's interpretation of ASGI is that there aren't very many different abstractions. As a result, I can hold the whole framework and its order of operations in my head, so introducing a new kind of middleware-thing that only gets applied after the router matches a path doesn't sound so great.

On a related note, I've also been thinking for a while about how you could swap Starlette's router for a different type of router, like a radix tree, which has become pretty popular as the fastest router implementation for frameworks in Go, Javascript, Rust, etc. I wrote a radix tree router in Python at work for a project which was intended to have a couple hundred different routes, and then I puzzled over whether I should pitch it to the Starlette project as an alternate router implementation, maybe even a drop-in replacement for the stock router. To my knowledge, Python doesn't have any web frameworks with a radix tree router, so it would be cool for the Starlette project to be the first in this area, but I digress...

[tomchristie]

Lastly, one thing I appreciate about Starlette's interpretation of ASGI is that there aren't very many different abstractions. As a result, I can hold the whole framework and its order of operations in my head, so introducing a new kind of middleware-thing that only gets applied after the router matches a path doesn't sound so great.

Indeed.

[adriangb]

the problem in the BaseHttpMiddleware class: it encourages developers to think they're getting a complete Request or Response and this confuses things like Background

I agree that thinking about getting "the whole thing" anywhere is problematic because at the end of the day it's all just a stream of bytes.

That said, the BackgroundTask issue is actually an implementation detail that @jhominal actually fixed, there's still the issue of the reading the request body.

Starlette could offer is a RequestMapper class, which is like a map over a Request, to produce something like an RequestA -> RequestB before that request instance gets passed to a handler

So would this be mapping just the headers? Or also the body? I'm curious what the actual API would look like, I just can't exactly picture it...

introducing a new kind of middleware-thing that only gets applied after the router matches a path doesn't sound so great

I experimented with something like this. Here's the API I came up with: https://gist.github.com/adriangb/9c293cca43946cfdfde721a4d7f44d52

I was thinking one could get fancy and incorporate the Matchers into the router itself (so instead of applying them at the end they become a part of the routing state machine). This is interesting and in theory more performant but at the cost of increased complexity. I think that like you both said, there's just something really nice about the simplicity of being "pure ASGI" without any other abstractions.