Comment by nzeid
1 day ago
Also, embedded servers are now much much much more popular. Stuff an HTTP server directly into your application and do whatever you gotta do without gateways.
1 day ago
Also, embedded servers are now much much much more popular. Stuff an HTTP server directly into your application and do whatever you gotta do without gateways.
That is way! Unfortunately, sometimes you have to do path-based routing to different backends, and now you're back to needing a proxy between your clients and your applications.
This is the way only if you're operating in a trusted environment (eg. homelab, intranet) or you're sticking CloudFlare or some other "reverse proxy as a service" in front of it. If you expose an embedded HTTP app server directly to the Internet you're almost guaranteed to get pwned, as the Internet has now become an extremely hostile place.
Go's embedded HTTP server can handle it just fine: https://blog.gopheracademy.com/advent-2016/exposing-go-on-th...
These are often not enough ‘battle-tested” and come with a warning to never expose to public internet. So then you put a WAF in front of it, and you are back to HTTP reverse proxy setup.
I've always chuckled at this. Just don't used bad HTTP server libraries. I wouldn't put something like that on my intranet either.
But even if you disagree with me the point is that I can count on only one hand the number of times I went "oh man, I need a FastCGI middle end".
I agree with your point but this is the reality:
F.E. Python stdlib http.server comes with a warning: Warning http.server is not recommended for production. It only implements basic security checks.
The `standard` way is then to use WSGI or ASGI, not FastCGI, but it is similar interface implementation.