And even when it is HTTP, as other commenters said, the reverse proxy is able to handshake connections to the backend much more quickly than an actual remote client would, so it's still advantageous to use http/2 streams for the slower part of the connection.
That's just called a web server and not a reverse proxy then. Both are just evolutions of CGI.
At a startup I was working on a few years ago, I set up mitmproxy in dev and eventually if memory serves right I also sometimes enabled it in prod to debug things.
That being said, we did not have a lot of users. We had in fact very very few users at the time.
I’d totally pay a cloud provider to just do this and forward requests to my port 80 or 443 with self signed certificates.
Https+acme is already open to this attack vector, so why inconvenience myself by pretending it is not?
So inserting mitmproxy into the setup was just a case of putting it between the Nginx or Caddy that did TLS termination, and the web server that served the backend API. So to mitmproxy it was all plain HTTP traffic passing through it, locally on the same machine.
I bound the mitmweb web UI to the VPN interface so that us devs could connect to the dev server with VPN and then have access to the mitmweb web UI to inspect requests and responses.
The servers which run the frameworks have to http/3. In most cases the advantages should be transparent to the developers.
Since http/3 uses udp to send the fragments, duplicate packet information doesn’t have to be sent.
Kind of funny the newer protocol effectively works in the opposite direction of GraphQl.