[HN Gopher] Nginx Development Guide
       ___________________________________________________________________
        
       Nginx Development Guide
        
       Author : hliyan
       Score  : 64 points
       Date   : 2023-08-16 12:55 UTC (10 hours ago)
        
 (HTM) web link (nginx.org)
 (TXT) w3m dump (nginx.org)
        
       | freecodyx wrote:
       | Nginx is an amazing piece of software, you can learn a lot from
       | it,
        
       | [deleted]
        
       | kitanata wrote:
       | [flagged]
        
       | michaelplshkv wrote:
       | There are a few additional ways to extend nginx without writing a
       | module in C.
       | 
       | - JavaScript: https://nginx.org/en/docs/njs/ and
       | https://github.com/nginx/njs-examples
       | 
       | - Lua: https://github.com/openresty/lua-nginx-module
       | 
       | - Rust: https://github.com/nginxinc/ngx-rust
        
         | dekobon wrote:
         | Proxy WASM appears to be supported thanks to a project from
         | Kong: https://github.com/Kong/ngx_wasm_module
         | 
         | I haven't tried it yet, but it looks promising.
        
       | commandersaki wrote:
       | These days I'd rather develop on Caddy than Nginx.
        
         | mholt wrote:
         | This is exactly why I made Caddy. :) Glad to hear you also
         | prefer it!
        
         | monlockandkey wrote:
         | Would love a rust version of caddy. Performance of Cady vs
         | nginx is not as high. But overall an amazing project
        
         | nicbou wrote:
         | I have not tried Caddy much, but Nginx and its numerous
         | footguns are getting a little old. Nowadays I just copy and
         | paste from my own projects. Otherwise I always have to figure
         | which defaults are unreasonable and will bite me when I least
         | expect it.
         | 
         | I got Caddy to run on my vacuum cleaner in a few minutes with
         | no prior experience. I think that's pretty cool.
        
         | numlock86 wrote:
         | Caddy is cool if you want sane defaults and not bother with
         | anything for simple hosting. As soon as you get any drop of
         | "not the default" poured into the mix the configuration becomes
         | quite tedious really fast. I recommend Caddy to people getting
         | into web stuff or that need something simple even if it's a
         | production environment at this point. But anything "tuned" ends
         | up with Nginx.
        
           | mholt wrote:
           | We have a lot of larger use cases including enterprise that
           | manage their advanced configurations quite easily. but if you
           | have specific suggestions I'd be happy to consider them.
        
         | dspillett wrote:
         | Have there been any good in-depth comparisons of the two
         | recently (from an admin/user PoV, out-of-the-box featureset &
         | performance for common tasks). I've not seen anything recent
         | that isn't entirely superficial (little more than "I prefer the
         | config format", which while valid isn't exactly in-depth or in-
         | bredth).
        
           | otbutz wrote:
           | https://news.ycombinator.com/item?id=32865497
        
             | mholt wrote:
             | Yeah. tldr:
             | 
             | - Both Caddy and nginx are really fast.
             | 
             | - Both can handle high traffic loads.
             | 
             | - Caddy and nginx have different failure modes. Nginx will
             | drop requests. Caddy will hang onto them and serve them
             | even if it takes longer.
             | 
             | (Note that "Caddy" is basically equivalent to "Go" -- we
             | use its std lib HTTP implementation. It's really comparing
             | Go and C.)
        
           | DistractionRect wrote:
           | For me, it's that I'm constantly bitten by nginx vs nginx
           | plus, having to lookup hacks to do the most basic things.
           | There's just a ton of friction to configurating nginx from
           | scratch which, IMO, isn't there with caddy.
        
           | nhatcher wrote:
           | Both are great technologies and I use them both. My way of
           | thinking these days is "use Caddy until there is a reason for
           | nginx". When I am developing a web application, I use Caddy
           | in my dev server as a proxy for my front end server so you
           | get hot reloading and stuff and the the backend dev server.
           | You need to have three things up but works for me. It's nice
           | to have a single binary!
        
           | Macha wrote:
           | So I've been slowly moving from nginx to Caddy in new
           | projects (old projects still use nginx).
           | 
           | The reasons for this are:
           | 
           | 1. Automatic ACME integration in Caddy compared to the mess
           | of containers something like nginx-proxy-manager is or the
           | unreliability of external solutions like certbot or acme.sh
           | 
           | 2. nginx's config. Footguns like if are well known, but even
           | just if you want to deploy a nginx server with virtual hosts,
           | did you know that if there is no Host header nginx serves the
           | site evaluated first in its config file (even if the site has
           | a server_name directive)? This is fine for an enterprise
           | deployment where you probably only have one site behind nginx
           | anyway, but as someone who has their side projects share
           | servers to cut down on costs, it's really undesirable. There
           | is a way around it by setting up a default host to explicitly
           | serve errors, but it's just a chore I don't have on Caddy.
           | 
           | 3. I can use Caddy on the CLI for testing also, in a way
           | that's a more advanced replacement for python -m http.server
           | etc. for more advanced use cases, or even just setting up
           | server config rules.
        
             | dekobon wrote:
             | Regarding #1, NGINX has created a project to make ACME
             | integration easier. It is quite new, so I doubt it will
             | replace your use of Caddy, but it is worth consideration.
             | 
             | https://github.com/nginx/njs-acme
        
             | morelisp wrote:
             | > did you know that if there is no Host header nginx serves
             | the site evaluated first in its config file (even if the
             | site has a server_name directive)?
             | 
             | Before that it goes to the one named "" and if that doesn't
             | exist, the one with default_server.
             | 
             | If traffic with no Host header went to no server by
             | default, people would also call that a footgun...
        
               | Macha wrote:
               | Setting a server_name is something you need to opt into.
               | So I feel it should be required to match to serve that
               | vhost. If you didn't want it to apply only to the right
               | vhost, don't configure it to require a specific vhost?
        
         | excitom wrote:
         | Irrelevant to this post.
        
         | dvhh wrote:
         | Really depends on your preferred programing language I guess.
         | And the kind of feature you would like to implement.
        
         | chasd00 wrote:
         | > These days I'd rather develop on Caddy than Nginx.
         | 
         | do you mean develop on Caddy itself or use Caddy as a webserver
         | for a website you're developing?
        
           | commandersaki wrote:
           | I meant developing on Caddy itself. Since it is in Go, it
           | would be remarkably easier than smashing out (async) C. Caddy
           | also has a plugin/module architecture as well.
        
         | okasaki wrote:
         | I got caught in the hype and switched to caddy. After a year
         | I'm now back with nginx and happier than ever.
         | 
         | I understand that one can probably methodologically master
         | caddy, but from the perspective of someone who has been running
         | web servers for decades and just needs to get things done, my
         | god, caddy has the worst documentation of any product I've ever
         | seen, and the most confusing configuration I can possibly
         | imagine.
         | 
         | Confusion over v1/v2/json/yaml formats, documentation showing
         | tiny snippets without telling how where they fit, etc. Not even
         | ChatGPT4 can write caddy configuration.
         | 
         | For a long time I thought that my caddy config was blocking all
         | IPs except the ones I listed. Turns out that no. The shit I
         | wrote did nothing.
         | 
         | TLDR: Don't fall for the hype. Nginx is excellent.
        
         | francislavoie wrote:
         | For ref: https://caddyserver.com/docs/extending-caddy
         | 
         | Disclaimer: I help maintain Caddy
        
       | pelagicAustral wrote:
       | hahaha so fitting... I've been struggling with an nginx
       | configuration for two days now. I'm just about to try Caddy...
        
         | adr1an wrote:
         | Caddyfile have easier syntax imho. Now, I wonder how does it
         | compares to traefik..
        
           | c0wb0yc0d3r wrote:
           | If you are using caddy in k8s or docker (compose), you are
           | wasting time. Traefik can be configured in almost every way
           | via labels on pods/containers. It's also frustrating that you
           | have to compile plugins into caddy to use them.
        
           | jiehong wrote:
           | Caddy is more like a traditional web server. It does serve
           | files while it's not possible by default with traefik for
           | example.
        
       | ChrisArchitect wrote:
       | What's new here?
        
       | ilrwbwrkhv wrote:
       | Aah nginx my first love when it comes to networking. Back in the
       | day I played around with it so much. Such a good piece of
       | technology and really taught me the benefits of being highly
       | performant, low memory. There is just something elegant about it.
        
       | 0xDEF wrote:
       | The following article is maybe slightly outdated by now but gives
       | an overview of the nginx architecture. Probably a good read
       | before diving into the nginx codebase:
       | 
       | https://aosabook.org/en/v2/nginx.html
        
       ___________________________________________________________________
       (page generated 2023-08-16 23:02 UTC)