4 ms·

NGINX has so many nice reverse proxy tools out of the box that it's still very appealing to just plop it in front of any service (much less a Go service). Perf

by nkozyra 10y ago

NGINX has so many nice reverse proxy tools out of the box that it's still very appealing to just plop it in front of any service (much less a Go service). Performance & failsafe is a big part of the appeal, but so is local caching, traffic splitting (for A/B testing or regional versions), etc. It's hard to ignore that when choosing to expose your server directly or put it behind NGINX. Unless you use none of these things, you'll end up reinventing a bunch of wheels.

weberc2 10y ago
Given that Go's HTTP interfaces are very composable, and assuming there are libraries to do caching and traffic splitting, you wouldn't be reinventing wheels. At that point, it seems that the question is whether you prefer to manage NGINX config files or write your configuration in Go.
- nkozyra 10y ago
  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.
  - weberc2 10y ago
    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.
    - nkozyra 10y ago
      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.
      - weberc2 10y ago
        > It's more than filling out a few structs, though. How do you know how many lines are required to configure hypothetical middleware? > No go gets How is static compilation worse than `apt-get install` or `docker run`? > No middleware It's another process... why would running another process be better than middleware? > it's well tested, mature and backed by software that powers a majority of the web. Granted. It seems like this is the only clear win for NGINX, and it may well change if Go libraries mature. Time will tell.
        nkozyra 10y ago
        > 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.
        234dd57d2c8db 10y ago
        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? Separation of concerns, use it!!
- paulddraper 10y ago
  > whether you prefer to manage NGINX config files or write your configuration in Go When it comes to these decisions, I use the Principal of Least Power (https://en.wikipedia.org/wiki/Rule_of_least_power https://en.wikipedia.org/wiki/Rule_of_least_power) If writing proxy_cache_path /path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=10g location / { proxy_cache my_cache; proxy_pass http://my_upstream; } gets me what I want without Turing-completeness, I'll choose that. Obviously, more complicated tasks require more complicated tools.
  - weberc2 10y ago
    I agree, when choosing between two configuration languages all else equal, choose the one with the least power. However, I think there are some advantages to choosing Go that might offset this rule--specifically simpler deployment and process topology. Further, if you know Go and not NGINX, the learning curve is (probably) better as well.
    - solidsnack9000 10y ago
      > ...if you know Go and not NGINX... This doesn't seem like a solid basis for making engineering decisions -- or any kind of decisions.
      - lox 10y ago
        On the contrary, it makes a lot more sense to build something in technology you have expertise in than it does to "use the right tool for the job". I'd rather have less tools to maintain at the expense of them being slightly worse fits.
        solidsnack9000 10y ago
        What I am referring to, is thinking that it is good to not know anything about the alternatives available to you and still make a decision. This doesn't always lead to the best decisions -- although by chance it can work out okay -- and it also has the effect of limiting your horizons. Now I can't say one should learn about every single web server out there, but when the choice is between a dedicated web server and a library in a particular programming language, there is really a lot to see on the other side. Rewrite rules and the wide variety of HTTP stats available for logging are both areas where web servers can give us new ideas. When I was much younger I thought, why learn databases? I can use Java, I know XML. Just open the XML file and add the records. There's XQuery for searching... The historical precursor for "Why not write everything in Go?" is "Why not write everything in Java?".

by nkozyra 10y ago

weberc2 10y ago

Given that Go's HTTP interfaces are very composable, and assuming there are libraries to do caching and traffic splitting, you wouldn't be reinventing wheels. At that point, it seems that the question is whether you prefer to manage NGINX config files or write your configuration in Go.

nkozyra 10y ago
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.
- weberc2 10y ago
  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.
  - nkozyra 10y ago
    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.
    - weberc2 10y ago
      > It's more than filling out a few structs, though. How do you know how many lines are required to configure hypothetical middleware? > No go gets How is static compilation worse than `apt-get install` or `docker run`? > No middleware It's another process... why would running another process be better than middleware? > it's well tested, mature and backed by software that powers a majority of the web. Granted. It seems like this is the only clear win for NGINX, and it may well change if Go libraries mature. Time will tell.
      - nkozyra 10y ago
        > 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.
      - 234dd57d2c8db 10y ago
        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? Separation of concerns, use it!!
paulddraper 10y ago
> whether you prefer to manage NGINX config files or write your configuration in Go When it comes to these decisions, I use the Principal of Least Power (https://en.wikipedia.org/wiki/Rule_of_least_power https://en.wikipedia.org/wiki/Rule_of_least_power) If writing proxy_cache_path /path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=10g location / { proxy_cache my_cache; proxy_pass http://my_upstream; } gets me what I want without Turing-completeness, I'll choose that. Obviously, more complicated tasks require more complicated tools.
- weberc2 10y ago
  I agree, when choosing between two configuration languages all else equal, choose the one with the least power. However, I think there are some advantages to choosing Go that might offset this rule--specifically simpler deployment and process topology. Further, if you know Go and not NGINX, the learning curve is (probably) better as well.
  - solidsnack9000 10y ago
    > ...if you know Go and not NGINX... This doesn't seem like a solid basis for making engineering decisions -- or any kind of decisions.
    - lox 10y ago
      On the contrary, it makes a lot more sense to build something in technology you have expertise in than it does to "use the right tool for the job". I'd rather have less tools to maintain at the expense of them being slightly worse fits.
      - solidsnack9000 10y ago
        What I am referring to, is thinking that it is good to not know anything about the alternatives available to you and still make a decision. This doesn't always lead to the best decisions -- although by chance it can work out okay -- and it also has the effect of limiting your horizons. Now I can't say one should learn about every single web server out there, but when the choice is between a dedicated web server and a library in a particular programming language, there is really a lot to see on the other side. Rewrite rules and the wide variety of HTTP stats available for logging are both areas where web servers can give us new ideas. When I was much younger I thought, why learn databases? I can use Java, I know XML. Just open the XML file and add the records. There's XQuery for searching... The historical precursor for "Why not write everything in Go?" is "Why not write everything in Java?".