OK, so 're-implement' the wheel. Using a variety of unrelated, dubiously-updated libraries.
I'm still not sure what the advantage of that is over using perhaps the most reliable, certainly most-used web server as a proxy in front of your app. I'm open to convincing, though.
How is filling out struct fields more complex than filling out config files? The principle advantage is system simplicity--everything deploys in a single file, no network topology to troubleshoot, fewer moving parts, no new highly-configurable tool to master. If the quality of those libraries is as poor as you suppose, then take NGINX by all means. I don't see any reason to make those assumptions, however.
I don't mean to overstate the advantages--I think both solutions are fine; neither will make or break your operation.
It's more than filling out a few structs, though. Traffic splitting or caching via NGINX can literally be done in a handful of lines. No go gets, no middleware and it's well tested, mature and backed by software that powers a majority of the web.
I use go net/http every day, in production. I trust it, but NGINX provides so much more battle tested functionality out of the box.
You're missing the sysadmin angle of this entirely. Nginx has amazing tooling around load balancing, configuration mgmt, multiple languages, logging options, rewrite rules, rate limiting, file upload size tuning, HTTP tuning in general, the list goes on and on. What if your site needs to support multiple backends like a JVM app, a wsgi app, and an old crufty cgi app. You gonna write backends for all that shit too in Go?
Sorry but I'm not going to be writing ansible code that modifies structs inside of some program then compiles said program. No thank you that sounds like crazy town. Also other sysadmins and infrastructure engineers will actually know how things work and won't have to go reading the source code for some crazy Go app program at 2am that also is a webserver for some reason?
You're free to not use nginx or Apache if you can validate that you are better off without them, but IMHO it sounds like a nightmare of "experimental homemade wheels" being muddled in with business logic.
> How do you know how many lines are required to configure hypothetical middleware?
Primarily through experience. Happy to be shown otherwise. Middleware usually takes a bit more configuration than that.
> Granted. It seems like this is the only clear win for NGINX, and it may well change if Go libraries mature. Time will tell.
We can quibble over whether it's the "only" win, but even so, it's a very, very big win. It's a single point of failure that handles a lot of features you'd have to replicate with various packages that lack the kind of support, maturity and community that NGINX has.
It's also about reproducing all the business logic provided by nginx, not just configuration. You can't pretend like net/http package gives you everything ngnix provides, that's a lie.
I'm still not sure what the advantage of that is over using perhaps the most reliable, certainly most-used web server as a proxy in front of your app. I'm open to convincing, though.