20 ms·

The future of Nginx: Getting back to our open source roots

388 points by soheilpro 4y ago

kungfufrog 4y ago
To me it totally sounds like 'all those features (some bizarrely so) we locked behind a commercial license to extract money from you' has resulted in people looking for alternatives as soon as the use case exceeded the capabilities of the open source version. Kubernetes and the ecosystem is eating their lunch for more complex service mesh deployment scenarios where nginx is basically an interchangeable dumb proxy, and doing it with generally new and free open source products, so here, have some more stuff we've kept gated behind an expensive license/subscription so we can stay relevant. I don't say this to be ungrateful about what nginx has provided for free, it's great, thank you. But the post also feels like a cynical take about what the value of open source truly is.
- miohtama 4y ago
  My web server path has been Apache -> (Varnish) -> Nginx -> Caddy. This outside programming language specific servers like Waitress or Express.js. I love the fact that Caddy is a single binary I can run for simple use cases without configuration file. Plus the built-in Let’s Encrypt support. Nginx is definitely on defence here unless you need “web scale” servers.
  - kungfufrog 4y ago
    Also a huge fan of Caddy!!! Such a smart design and incredibly useful piece of software!
    - FooBarWidget 4y ago
      But since we're replying to a comment that's criticial about Nginx's commercialization: Caddy also tried to commercialize, and for some time they got way more criticism for that. Are those concerns no longer applicable?
      - francislavoie 4y ago
        Yes, no longer applicable. https://github.com/caddyserver/caddy/issues/2786 https://github.com/caddyserver/caddy/issues/2786
  - ksbrooksjr 4y ago
    Yeah Caddy's developer experience is unrivaled when it comes to setting up SSL. You don't have to run Certbot or manage certificates manually. If you give it a hostname to proxy to, it just handles certificate management seamlessly in the background. The real killer feature for me is the Cloudflare module. It allows you to use the acme DNS challenge, which means you can test your SSL setup without exposing your server to the public internet.
    - manishsharan 4y ago
      certbot has dns plugin for nearly all DNS providers including Route53 and Cloudflare. I have been using LE certs on the nginx server on my developer environment without any issues ,other can copying over the certs.
      - ksbrooksjr 4y ago
        Certbot is fine, but it’s nice to have that functionality built directly into the reverse proxy as opposed to having to configure and update multiple tools. I would ideally like to see Nginx integrate a subset of Certbot’s feature set into their code base especially given that offloading SSL is one of the primary use cases of Nginx.
  - jenia2022 4y ago
    Why do you have so many reverse proxies hooked up to each other? Specially Apache and Nginx? I suppose you're using Caddy for its LetsEncrypt support?
    - kungfufrog 4y ago
      They're talking about a timeline of products that they've used. Not an architecture.
      - jenia2022 4y ago
        Oh. Ok. Thanks
  - mholt 4y ago
    To clarify, Caddy absolutely can deal "web scale" as proven by companies like Fathom, Stripe, and many others. (The Go standard library powers many of Google's, Cloudflare's, and Netflix's infrastructure, and Caddy is a relatively thin wrapper over that.)
- kungfufrog 4y ago
  Also, if you need further evidence of this, look at the MARA diagram. It basically spells it out. There's 2 products in that stack that are branded: nginx and Kubernetes, the rest is noise, with nginx positioned as the only component for traffic ingress. Also if that napkin scribbling constitutes an "architecture"...
- 0xbadcafebee 4y ago
  "Going forward, all NGINX projects will be born and hosted on GitHub because that’s where the developer and open source communities work. [..] We pledge to be more open to contributions, more transparent in our stewardship, and more approachable to the community. We will follow all expected conventions for modern open source work and will be rebuilding our GitHub presence, adding Codes of Conduct to all our projects, and paying close attention to community feedback." "we recognize that many critical features which developers now view as table stakes are on the wrong side of the paywall for NGINX Open Source and NGINX Plus. For example, DNS service discovery is essential for modern apps. Our promise is to make those critical features free by adding them to NGINX Open Source. We haven’t yet decided on all of the features to move and we want your input. Tell us how to optimize your experience as developers. We are listening." "The NGINX Kubernetes Gateway is also something of an olive branch we’re extending to the community. We realize it complicated matters when we created both a commercial and an open source Ingress controller for Kubernetes, both different from the community Ingress solution (also built on NGINX). The range of choices confused the community and put us in a bad position. It’s pretty clear that the Gateway API is going to take the place of the Ingress controller in the Kubernetes architecture. So we are changing our approach and will make the NGINX Kubernetes Gateway – which will be offered only as an open source product – the focal point of our Kubernetes networking efforts (in lockstep with the evolving standard). It will both integrate and extend into other NGINX products and optimize the developer experience on Kubernetes." It sounds pretty honest and positive to me. And I'm the first person to call bullshit on corporate doublespeak. Most other companies would just put more money into B2B sales rather than courting OSS devs/free users and admitting when their strategy was stupid (actually their language is evasive, but w/e). Of course hindsight's 20/20; let's see if they make good on these promises.
  - mistrial9 4y ago
    > NGINX projects will be born and hosted on GitHub because that’s where the developer and open source communities work. friendly tip - not everything is on Github, not everyone is on Github, everything can be on Github but that's not the only place everything can be
    - 4y ago
- colechristensen 4y ago
  I would put it in a more positive light. Long ago, nginx was excellent providing way more than Apache or other alternatives. Then they added features which were pretty advanced and uncommon behind a pay wall. Many of those features have gone from fancy to expected, and they transitioned too late to making them open source. The free product went through a slow decline from excellent to artificially crippled, and they’re changing course, which should be applauded. On top of that they didn’t take away features to cripple their product for money, just what is basically necessary these days is so much more than it was years ago.
  - kungfufrog 4y ago
    I don't disagree with your take. I just find it disheartening that it took what presumably they must perceive as a threat to their revenue stream to start listening to developers/engineers about the role open source can play in their product offering and what effect that might have on the "community" around nginx.
    - folkrav 4y ago
      To me it sounds rather par for the course as far as open-source projects going partially paid, no?
  - bcrosby95 4y ago
    I thought nginx gained popularity because of it's, at the time, superior concurrency model.
- deleted 4y ago
  [deleted]
  - deleted 4y ago
    [deleted]
adeptima 4y ago
It's a very good time to go back to the roots. Especially in the context of HTTP3 and QUIC. #### Videos - The Internet just changed with Robin Marx and David Bombal https://www.youtube.com/watch?v=cdb7M37o9sU https://www.youtube.com/watch?v=cdb7M37o9sU - QUIC 101 with David Schinazi https://www.youtube.com/watch?v=dQ5AND4DPyU https://www.youtube.com/watch?v=dQ5AND4DPyU - Decrypting TLS, HTTP/2 and QUIC with Wireshark https://www.youtube.com/watch?v=yodDbgoCnLM https://www.youtube.com/watch?v=yodDbgoCnLM It's a great pleasure to read/watch Robin Marx and David Bombal #### HTTP3 core concepts - HTTP/3 From A To Z: Core Concepts Part 1 https://www.smashingmagazine.com/2021/08/http3-core-concepts-part1/ https://www.smashingmagazine.com/2021/08/http3-core-concepts... - HTTP/3: Performance Improvements Part 2 https://www.smashingmagazine.com/2021/08/http3-performance-improvements-part2/ https://www.smashingmagazine.com/2021/08/http3-performance-i... - HTTP/3: Practical Deployment Options Part 3 https://www.smashingmagazine.com/2021/09/http3-practical-deployment-options-part3/ https://www.smashingmagazine.com/2021/09/http3-practical-dep... - https://thenewstack.io/http-3-is-now-a-standard-why-use-it-and-how-to-get-started/ https://thenewstack.io/http-3-is-now-a-standard-why-use-it-a... ### Test Learn QUIC - https://cloudflare-quic.com/ https://cloudflare-quic.com/ - https://quic.nginx.org/ https://quic.nginx.org/ - https://http3.is/ https://http3.is/ - https://geekflare.com/tools/http3-test https://geekflare.com/tools/http3-test
fb03 4y ago
Nginx is a superb piece of software but for me it has largely been superseded by Caddy. I like it for its sane defaults, you get most things working from the get go and a fairly high score on the 'rate your webserver security' checkers.
- folkrav 4y ago
  I seem to remember Caddy having some features behind a rather restrictive license - or something like that, my memory is failing me - that made me not consider it at all. But it's been a while, easily a handful of years, and looking at it right now, it looks like they changed that. Seems to be all open-source/Apache 2.0 licensed. Am I crazy or did they really change the licensing situation? Cause it definitely looks pretty interesting, looking at current docs. Edit: Found it - they did switch to Apache 2.0, remove all usage restrictions and open-sourced it all https://github.com/caddyserver/caddy/issues/2786 https://github.com/caddyserver/caddy/issues/2786
  - ben_jones 4y ago
    I sympathize a lot with the licensing story of Caddy. /u/mholt has been a very active maintainer and participant in the larger Go community and has every right to create a commercial side to the project and receive compensation for their work. But licensing is hard. AWS abused the leniency of Elasticsearch's original OSS license, so now the industry is set back 10 years with new entrants trying to find the balance between inviting community participation and getting gob smacked by big corporate interests. Im not saying Elastic.co is an angel but its a lesson OSS projects have to take to heart, unfortunately. Thanks Amazon.
    - djhaskin987 4y ago
      I think my favorite reaction to Amazon's aggression is Grafana Labs. They released their code under Affero GPL but let you use a different license if you pay them. Sort of like a new version of the Qt model.
      - 4y ago
ramesh31 4y ago
It’s kind of hard to explain what a big deal NGINX/fastcgi was back in the day coming from httpd/mod_php. All of the sudden, a basic EC2 instance could handle orders of magnitude more concurrent requests. Before NodeJS was a thing, it opened up whole new possibilities for my company at the time. Not sure what my point is. But NGNIX has a special place in my developer heart and it’s really encouraging to hear this.
- ggm 4y ago
  I am probably in the dying cohort who were mod_python, didn't make uplift to fastcgi and are somewhat mentally stuck in expectation of apache hooks and thin paralellism in our code. The fastcgi thing was true: I don't for a minute deny what you are saying. But it also stranded some "less agile" minds like me. I know significant sites using Perl use::CGI; still.
- thriftwy 4y ago
  Before nginx there was mod_accel for Apache which was hard to configure but provided same ballpark of performance reverse proxying. Earlier work of the same artist.
- jwmoz 4y ago
  I came from the same place, you're right, it felt like this super new hacker fast thing.
- xorcist 4y ago
  The big deal was FPM, the PHP FastCGI process manager. Apache had mod_fastcgi for half a decade before nginx even existed, and then got mod_fcgi, but it was not much good without any support from PHP (which was an even bigger deal back then).
- BirAdam 4y ago
  You can use Apache with FPM. However, Nginx was definitely what I chose to use. I was working in managed webhosting at the time, and it was just amazing how much could be done in Nginx without needing to track down some abandoned module like had to be done with Apache all the time.
cypres 4y ago
As long as Dynamic Configuration is locked behind an nginx plus-only API, these are hollow words. This is a must have feature for todays workloads (kubernetes or just very busy webservers) in production, and nginx will likely continue to lose market share to Envoy based alternatives where everything is configured through APIs, without needing to reload the server.
- kungfufrog 4y ago
  This is definitely addressed in the article. The relevant bits talk about moving features from the commercial version to the open source version, as well as the introduction of an open source nginx agent that can do the "dynamic config" on your behalf (via API I presume). I agree with your sentiment though! I hope they do follow through as nginx is generally an easy sell to others when trying to fill holes in your tech stack and otherwise pretty bulletproof.
  - cypres 4y ago
    Good catch! I hope this is applicable to the kubernetes ingress controller.
    - bithavoc 4y ago
      yeah, hopefully it helps replace a bunch of lua code from ingress-nginx
    - throwaway892238 4y ago
      Kubernetes will probably drop Ingress in favor of API Gateway in two years.
      - harpratap 4y ago
        That's just the API layer for configuration, you still need a proxy to route. Nginx will still stay relevant
- deleted 4y ago
  [deleted]
jarym 4y ago
I love nginx and while I use Caddy on my laptop all my servers are nginx. Now the dynamic configuration API is going open this will give Envoy a good run for its money. The big thing Envoy doesn’t do is static file serving and for smaller (anything but the largest…) deployments Nginx makes a ton more sense.
- harpratap 4y ago
  > Now the dynamic configuration API is going open this will give Envoy a good run for its money Wasn't dynamic configuration always available through OpenResty? It's based on Nginx too with extra Lua modules to fill the feature gaps
- mholt 4y ago
  What's keeping you from using Caddy in production? We designed it for that too :D PS. Have you seen Caddy's on-line config API? https://caddyserver.com/docs/api https://caddyserver.com/docs/api
  - derefr 4y ago
    Global rate-limiting bucketed by Basic-Auth-presented API key? Easy enough in Nginx; no idea how to do it with Caddy. When people say "production", they mean things like "QoS for a shared-multitenant system, in the presence of customers with really badly tuned and spiky request workloads, whose traffic you must nevertheless mostly accept."
    - mholt 4y ago
      If you can't already do it with the rate limit module I wrote, open an issue with your detailed requirements: https://github.com/mholt/caddy-ratelimit https://github.com/mholt/caddy-ratelimit -- should be pretty straightforward for the most part. > QoS for a shared-multitenant system, in the presence of customers with really badly tuned and spiky request workloads, whose traffic you must nevertheless mostly accept. Yah, we see that sometimes. Caddy usually handles it fine, sometimes with a bit of massaging the config.
lewisl9029 4y ago
This article came at an interesting timing for me, since I recently started to explore building my own CDN clusters on top of NGINX open source inspired by this article from Fly: https://fly.io/blog/the-5-hour-content-delivery-network/ https://fly.io/blog/the-5-hour-content-delivery-network/ I've worked with nginx in the past, and didn't have a great experience, so I was apprehensive diving in, but this time was very different. I think njs (their custom JS scripting environment) was a game changer. Support is built in to nginx core, and available by default in their docker containers, so it's much easier to get started with than Lua scripting. Their JS feature support has some quirks (no optional chaining, array destructuring, console.log's don't show up in logs, are some examples of things that threw me off) but overall nothing that blocked me from implementing the functionality I needed, and the integration points within the nginx config felt a lot more natural than I remember with Lua modules. I did run into a number of things that were locked behind their commercial offering that made me a bit uncomfortable betting on it for the long term compared to purely open source alternatives. Off the top of my head: - DNS discovery. There's a thread on the Fly example repo accompanying the blog post that describes the use case and proposes some workarounds: https://github.com/fly-apps/nginx-cluster/issues/2 https://github.com/fly-apps/nginx-cluster/issues/2. Life would be a lot simpler if DNS discovery from the commercial offering was just available (i.e. we can outright delete a brittle bash script that makes DNS queries and reloads nginx on a 5 second interval). This was mentioned in the article as something they're planning to open source. - Access to some kind of shared key-value store for custom caching logic in njs scripts. With Lua we could just connect to Redis, but njs can't seem to establish persistent network connections for now, so that's off the table. This wasn't mentioned in the article, but they did mention in this Github issue that they're planning on open sourcing their keyval module for this use case: https://github.com/nginx/njs/issues/437 https://github.com/nginx/njs/issues/437. I have some use cases where being able to connect to Redis would be ideal, since I'm already using Redis for caching across a bunch of other services, and syncing keyval across a cluster seems to be eventually consistent (https://docs.nginx.com/nginx/admin-guide/high-availability/zone_sync/ https://docs.nginx.com/nginx/admin-guide/high-availability/z...), but for most of my caching use cases it should be sufficient. So this article, along with their overall willingness to work with the community to identify and bring commercial features into open source (at least from what I've observed across their responses to Github issues) does a lot to alleviate those concerns. Though at the end of the day, I don't necessarily need every nginx feature to be in open source. I have no problems with paying for great software like nginx to support its development. But as a small bootstrapped founder, their current pricing structure (from what I could gather on the internet is ~ 2k-5k per running instance) is completely prohibitive. It'd probably require a revamp to the way they sell the software (i.e. self-serve onboarding and automatic license provisioning for smaller customers instead of having customers of all sizes go through expensive sales people), but I'd love to see a more progressive pricing structure with a lower barrier to entry for their commercial product.
nimbius 4y ago
note that this is nginx.com, the division of F5 networks that was purchased largely to staunch the bleeding from nginx, lvs, haproxy and other open source load balancers. the purchase was made in the same faith as oracles acquisition of mysql, albeit with less implosion so far. "part of f5" is written on the logo in almost imperceptible font, that it may evade the PTSD of managers familiar with f5 licenses.
XorNot 4y ago
The problem with nginx commercial was it didn't work with the actual resources developers can bring to bare. If an nginx commercial license solves a problem, and the answer is "great, $5000 a year please" then the developer can't take that to their manager - the problem isn't critical yet, may not become critical, and they'll be asked to look for any other solution to work around it (I've been the guy doing this). A per node, per core, per something license at a much lower rate would've saved them a lot of problems. Because $5 a month per node might get expensive quickly when scaling up, but thats a simple expense I can throw on the corporate credit card and then go "look, now the project is delivered".
- porker 4y ago
  A 1000x this. I see it with other software companies chasing enterprises (or at least VC backed companies) - Varnish Cache is a particularly egregious example. In the end it hurts them because a developer or consultant may find a problem that is worth the license fee to solve - but with no hands on experience of the product due to the cost, it's hard to recommend it and take the reputational risk in case it doesn't live up to its promises.
- karussell 4y ago
  Yes, they really miss the opportunity to get a foot into many smaller companies and scale up. For anything useful you need at least $10k/year (likely more), but what if you only need a tiny feature in addition to the open source software? Then this pricing feels just too much (although they of course have to financially support the open source software too) and it'll be very likely that you try to solve it with the open source nginx. If they have modules - why not sell these modules and attach a "reasonable" price to it?
moderation 4y ago
Exactly one year ago the same author published a blog post - "NGINX Sprint 2.0: Clear Vision, Fresh Code, New Commitments to Open Source" [0] It would be interesting to scorecard the progress made on promises made then. There is a lot of repetition. Feels a little hollow. 0. https://www.nginx.com/blog/nginx-sprint-2-0-clear-vision-fresh-code-new-commitments-to-open-source/ https://www.nginx.com/blog/nginx-sprint-2-0-clear-vision-fre...
- deleted 4y ago
  [deleted]
andrewstuart 4y ago
I used nginx for a very, very long time but abandoned it. I switched to Caddy because I just got so sick of the constant pain of certificates. Caddy does certificates automatically. I also was sick of the complexity of nginx configuration. I could get the things done that I needed to do but it was always painful and time consuming. I've worked out how to do in Caddy everything that I did in nginx though that took alot of time and effort, but I tend to create quite sophisticated web server configs. At this stage there's nothing really that nginx could offer that would bring me back from Caddy.
- steve_taylor 4y ago
  I’m the same. I’m able to host unlimited subdomains using wildcard TLS and unlimited apex domains using TLS on-demand, all from one Caddy config. It’s amazing. No disrespect to the good people behind nginx. Caddy is simply part of a new generation of web servers.
  - mrweasel 4y ago
    > Caddy is simply part of a new generation of web servers. I feel old now, as I continue to deploy Apache :-)
    - 1letterunixname 4y ago
      It's cool as long as you compile in mod_perl, use --with-mpm=prefork, set LC_ALL=C, and use /bin/csh. ;P
    - lsofzz 4y ago
      > I feel old now, as I continue to deploy Apache :-) we wrote bash scripts backends. don't worry about being old. keep going ;) some even had their cgi code running in kernel.. all the more reason to be merrier.
- vbezhenar 4y ago
  One pain point with caddy for me was cloudflare dns validation. I had to rebuild caddy from scratch, build my own container image. This process is slow as hell and very RAM-intensive, I had to add swap just for it. I wish they publish images with popular plugins built-in.
philsnow 4y ago
I don't know much of the history or politics. I've mostly been a "let's just use (open source, if it needs to be said out loud) nginx" fire-and-forget kind of dude for a while now because I mostly don't care about this layer... > We realize it complicated matters when we created [...] an open source Ingress controller for Kubernetes, [...] different from the community Ingress solution (also built on NGINX). > It’s pretty clear that the Gateway API is going to take the place of the Ingress controller in the Kubernetes architecture. So we [...] will make the NGINX Kubernetes Gateway – which will be offered only as an open source product[...] ... but these two bits very much give me a feeling like they're planting their flag here and offering an open source version so that there's no "need" to go making another one that they don't control.
- thinkmassive 4y ago
  I think you hit the nail on the head! Here’s a summary (from F5 Nginx) of the key difference between nginxinc/kubernetes-ingress and kubernetes/ingress-nginx: https://github.com/nginxinc/kubernetes-ingress/blob/main/docs/content/intro/nginx-ingress-controllers.md https://github.com/nginxinc/kubernetes-ingress/blob/main/doc...
preisschild 4y ago
I love the OpenResty nginx distribution (which is used by the official Kubernetes ingress-nginx). Makes most of the things you'd have to pay for with the normal nginx free.
- synthmeat 4y ago
  OpenResty with Redis on the same system - both Lua-powered - is a god-like power. Ability to do basically control and rewrite all your ingress AND egress and have some state via Redis over UNIX sockets. What's not to love? After all, it's what powers the bulk of internet. Granted, it sounds dreamier than it is, since a lot of the contraptions you could come up with might be better placed at application layer. But having operational ability to do these things ad-hoc, security advantages of manipulating at your own infra edge or performance boosts, sure does come in handy!
  - lsofzz 4y ago
    We did this on production (still runs at webscale) but we abandoned dev effort on it for ${reasons}. I _loved_ it though :) Hook Lua on the HTTP event processing stages and add icing on the cake with Lua modules to hand-off non-trivial stuffs..
emersion 4y ago
Heading: "Open Source Roots" What it actually means: "As part of this commitment to modernize, we are adding an NGINX Community channel on Slack" Oh right. It completely makes sense that open source roots involve a proprietary communication platform.
- matthewmacleod 4y ago
  Stop being silly; these are totally orthogonal concerns.
  - ddevault 4y ago
    "Stop being silly" is not a polite way to engage in a discourse. These choices matter. https://drewdevault.com/2022/03/29/free-software-free-infrastructure.html https://drewdevault.com/2022/03/29/free-software-free-infras...
- lawgimenez 4y ago
  Not really a fan of communities siloed into the Slacks or Discords. The only community I enjoyed was either in Stackoverflow chat or Google groups.
- tristan957 4y ago
  Yep. Electron uses Discord, and any time I want to interact with Electron developers on that platform, I remember that I hate Discord, and I don't care enough to actually open the application to send the message. Using Matrix would definitely be preferred for me since I have Element/Fractal open all day, everyday.
  - rs_rs_rs_rs_rs 4y ago
    You can use Discord in your browser, no need to install and open an application on your desktop.
    - tristan957 4y ago
eric4smith 4y ago
Nginx is missing automated TLS services. That’s the main reason we no longer use it for our multi-tenant SaaS systems. Otherwise… it’s great.
eric4smith 4y ago
Nginx is missing automated TLS services. That’s the main reason we no longer use it for our multi-tenant SaaS systems. Caddy powers our thousands of domains - although I will never be a fan of its JSON config file option, it works very very well for us. Otherwise… it’s great.
- mholt 4y ago
  Thanks for the feedback! What's your site/company?
  - eric4smith 4y ago
    Https://www.travelagencytribes.com
- francislavoie 4y ago
  > although I will never be a fan of its JSON config file option Well, if you use a Caddyfile, the JSON config is just an implementation detail. That decision shouldn't matter to you. The fact is, JSON is the best option for Caddy _at runtime_ to manage its config in memory, especially because Go has first-class support for unmarshaling JSON documents onto a tree of structs.
  - eric4smith 4y ago
    I love and use JSON every day. I just don't philosophically believe that it's the right thing for configuration. Too much scope for making errors if done by hand. And also if not doing it by hand, it means additional tooling to create the JSON file. Another layer to deal with with so many layers already. Also Go's first class support for JSON is not a reason for supporting JSON in configuration files. Pretty much every language supports JSON anyway, so whether it's "first class" or "second class" does not really matter. Anyway, we love and use Caddy here. We just don't use the JSON config file.
bayesian_horse 4y ago
A pain point with nginx: NTLM authentication But then again, that seems painful in any scenario.
soheil 4y ago
> Our users have done some pretty amazing things, everything from innovative cache purging Reminds of the days that Varnish + Apache was a thing and you had to invalidate cache more or less manually.
soheil 4y ago
> three words: modernize, optimize, and extend. We intend to make sure these are not just business buzzwords Why does everything have to be modernized? Nginx is awesome not because it tried to keep up with the ilks of ill-thought servers that came and went faster than a flash in the pan. No let’s not put it on GitHub and have every literal person contribute. Elegant architectures and code like this don’t just happen because someone “modernized”.
perlgeek 4y ago
> A quiet but incredibly innovative corner of the NGINX universe is NGINX JavaScript (njs), which enables developers to integrate JavaScript code into the event‑processing model of the NGINX HTTP and TCP/UDP (Stream) modules and extend NGINX configuration syntax to implement sophisticated capabilities. That sounds pretty similar (in spirit, at least) to mod_perl etc. in Apache. Does anybody happen to know a writeup that compares the two?
- excitom 4y ago
  NGINX has a perl module dating back to the early days, very much like Apache mod_perl. The njs module just gives you a more modern language option.
iknownothow 4y ago
I am an Nginx user and I really do not want to go away from here. It's too performant and too mature. It has a terrible UI problem. I don't want to learn a new tool. All I ask is a Caddy style JSON configuration format for Nginx. And don't just implement some random JSON schema either, please create a well designed schema that is extensible. Take Prometheus [1] or Alertmanager [2] as examples of well designed and extensible schemas. Just give me some basic features first, easy HTTPS, easy reverse proxy, easy rate limiting. You can release the rest of the advanced features in your own time. [1] https://prometheus.io/docs/prometheus/latest/configuration/configuration/ https://prometheus.io/docs/prometheus/latest/configuration/c... [2] https://prometheus.io/docs/alerting/latest/configuration/ https://prometheus.io/docs/alerting/latest/configuration/
- mholt 4y ago
  Did you know Caddy lets you use an NGINX config? https://caddyserver.com/docs/config-adapters https://caddyserver.com/docs/config-adapters -- no need to "learn" another tool (except for a command or two, perhaps).
yalogin 4y ago
I don’t follow nginx so what I say might not mean much, but this is a weird read for me. It reads hollow, like a PR document but at the same time also feels abut like trying to make amends to the open source world but fails at that a bit. Was there some history here where nginx the company did wrong by the community or was the community aggrieved with nginx? Something happened for sure. Also they should have stayed away from erstwhile Ballmer phrases like “open source is not production ready”, who thinks that way? Tells me that this is not written by someone that contributes or understands open source at all.
pachico 4y ago
If they just offered a decent Prometheus exporter rather than the shitty one that comes with the free version...
lsofzz 4y ago
this is NGINX Inc. talking. grain of salt.
lsofzz 4y ago
Run Kubernetes. Install the open-source Kubernetes ingress controller with your favourite load balancer. I'd wager that'd solve majority of your use cases.
- lsofzz 4y ago
manishsharan 4y ago
Is there any plan to port the dynamic configuration capability of Nginx+ to plain old Nginx? https://clouddocs.f5.com/training/community/nginx/html/class1/module3/lab2.html https://clouddocs.f5.com/training/community/nginx/html/class...

388 points by soheilpro 4y ago

To me it totally sounds like 'all those features (some bizarrely so) we locked behind a commercial license to extract money from you' has resulted in people looking for alternatives as soon as the use case exceeded the capabilities of the open source version. Kubernetes and the ecosystem is eating their lunch for more complex service mesh deployment scenarios where nginx is basically an interchangeable dumb proxy, and doing it with generally new and free open source products, so here, have some more stuff we've kept gated behind an expensive license/subscription so we can stay relevant. I don't say this to be ungrateful about what nginx has provided for free, it's great, thank you. But the post also feels like a cynical take about what the value of open source truly is.

miohtama 4y ago
My web server path has been Apache -> (Varnish) -> Nginx -> Caddy. This outside programming language specific servers like Waitress or Express.js. I love the fact that Caddy is a single binary I can run for simple use cases without configuration file. Plus the built-in Let’s Encrypt support. Nginx is definitely on defence here unless you need “web scale” servers.
- kungfufrog 4y ago
  Also a huge fan of Caddy!!! Such a smart design and incredibly useful piece of software!
  - FooBarWidget 4y ago
    But since we're replying to a comment that's criticial about Nginx's commercialization: Caddy also tried to commercialize, and for some time they got way more criticism for that. Are those concerns no longer applicable?
    - francislavoie 4y ago
      Yes, no longer applicable. https://github.com/caddyserver/caddy/issues/2786 https://github.com/caddyserver/caddy/issues/2786
- ksbrooksjr 4y ago
  Yeah Caddy's developer experience is unrivaled when it comes to setting up SSL. You don't have to run Certbot or manage certificates manually. If you give it a hostname to proxy to, it just handles certificate management seamlessly in the background. The real killer feature for me is the Cloudflare module. It allows you to use the acme DNS challenge, which means you can test your SSL setup without exposing your server to the public internet.
  - manishsharan 4y ago
    certbot has dns plugin for nearly all DNS providers including Route53 and Cloudflare. I have been using LE certs on the nginx server on my developer environment without any issues ,other can copying over the certs.
    - ksbrooksjr 4y ago
      Certbot is fine, but it’s nice to have that functionality built directly into the reverse proxy as opposed to having to configure and update multiple tools. I would ideally like to see Nginx integrate a subset of Certbot’s feature set into their code base especially given that offloading SSL is one of the primary use cases of Nginx.
- jenia2022 4y ago
  Why do you have so many reverse proxies hooked up to each other? Specially Apache and Nginx? I suppose you're using Caddy for its LetsEncrypt support?
  - kungfufrog 4y ago
    They're talking about a timeline of products that they've used. Not an architecture.
    - jenia2022 4y ago
      Oh. Ok. Thanks
- mholt 4y ago
  To clarify, Caddy absolutely can deal "web scale" as proven by companies like Fathom, Stripe, and many others. (The Go standard library powers many of Google's, Cloudflare's, and Netflix's infrastructure, and Caddy is a relatively thin wrapper over that.)
kungfufrog 4y ago
Also, if you need further evidence of this, look at the MARA diagram. It basically spells it out. There's 2 products in that stack that are branded: nginx and Kubernetes, the rest is noise, with nginx positioned as the only component for traffic ingress. Also if that napkin scribbling constitutes an "architecture"...
0xbadcafebee 4y ago
"Going forward, all NGINX projects will be born and hosted on GitHub because that’s where the developer and open source communities work. [..] We pledge to be more open to contributions, more transparent in our stewardship, and more approachable to the community. We will follow all expected conventions for modern open source work and will be rebuilding our GitHub presence, adding Codes of Conduct to all our projects, and paying close attention to community feedback." "we recognize that many critical features which developers now view as table stakes are on the wrong side of the paywall for NGINX Open Source and NGINX Plus. For example, DNS service discovery is essential for modern apps. Our promise is to make those critical features free by adding them to NGINX Open Source. We haven’t yet decided on all of the features to move and we want your input. Tell us how to optimize your experience as developers. We are listening." "The NGINX Kubernetes Gateway is also something of an olive branch we’re extending to the community. We realize it complicated matters when we created both a commercial and an open source Ingress controller for Kubernetes, both different from the community Ingress solution (also built on NGINX). The range of choices confused the community and put us in a bad position. It’s pretty clear that the Gateway API is going to take the place of the Ingress controller in the Kubernetes architecture. So we are changing our approach and will make the NGINX Kubernetes Gateway – which will be offered only as an open source product – the focal point of our Kubernetes networking efforts (in lockstep with the evolving standard). It will both integrate and extend into other NGINX products and optimize the developer experience on Kubernetes." It sounds pretty honest and positive to me. And I'm the first person to call bullshit on corporate doublespeak. Most other companies would just put more money into B2B sales rather than courting OSS devs/free users and admitting when their strategy was stupid (actually their language is evasive, but w/e). Of course hindsight's 20/20; let's see if they make good on these promises.
- mistrial9 4y ago
  > NGINX projects will be born and hosted on GitHub because that’s where the developer and open source communities work. friendly tip - not everything is on Github, not everyone is on Github, everything can be on Github but that's not the only place everything can be
  - 4y ago
colechristensen 4y ago
I would put it in a more positive light. Long ago, nginx was excellent providing way more than Apache or other alternatives. Then they added features which were pretty advanced and uncommon behind a pay wall. Many of those features have gone from fancy to expected, and they transitioned too late to making them open source. The free product went through a slow decline from excellent to artificially crippled, and they’re changing course, which should be applauded. On top of that they didn’t take away features to cripple their product for money, just what is basically necessary these days is so much more than it was years ago.
- kungfufrog 4y ago
  I don't disagree with your take. I just find it disheartening that it took what presumably they must perceive as a threat to their revenue stream to start listening to developers/engineers about the role open source can play in their product offering and what effect that might have on the "community" around nginx.
  - folkrav 4y ago
    To me it sounds rather par for the course as far as open-source projects going partially paid, no?
- bcrosby95 4y ago
  I thought nginx gained popularity because of it's, at the time, superior concurrency model.
deleted 4y ago
[deleted]
- deleted 4y ago
  [deleted]

adeptima 4y ago

It's a very good time to go back to the roots. Especially in the context of HTTP3 and QUIC. #### Videos - The Internet just changed with Robin Marx and David Bombal https://www.youtube.com/watch?v=cdb7M37o9sU https://www.youtube.com/watch?v=cdb7M37o9sU - QUIC 101 with David Schinazi https://www.youtube.com/watch?v=dQ5AND4DPyU https://www.youtube.com/watch?v=dQ5AND4DPyU - Decrypting TLS, HTTP/2 and QUIC with Wireshark https://www.youtube.com/watch?v=yodDbgoCnLM https://www.youtube.com/watch?v=yodDbgoCnLM It's a great pleasure to read/watch Robin Marx and David Bombal #### HTTP3 core concepts - HTTP/3 From A To Z: Core Concepts Part 1 https://www.smashingmagazine.com/2021/08/http3-core-concepts-part1/ https://www.smashingmagazine.com/2021/08/http3-core-concepts... - HTTP/3: Performance Improvements Part 2 https://www.smashingmagazine.com/2021/08/http3-performance-improvements-part2/ https://www.smashingmagazine.com/2021/08/http3-performance-i... - HTTP/3: Practical Deployment Options Part 3 https://www.smashingmagazine.com/2021/09/http3-practical-deployment-options-part3/ https://www.smashingmagazine.com/2021/09/http3-practical-dep... - https://thenewstack.io/http-3-is-now-a-standard-why-use-it-and-how-to-get-started/ https://thenewstack.io/http-3-is-now-a-standard-why-use-it-a... ### Test Learn QUIC - https://cloudflare-quic.com/ https://cloudflare-quic.com/ - https://quic.nginx.org/ https://quic.nginx.org/ - https://http3.is/ https://http3.is/ - https://geekflare.com/tools/http3-test https://geekflare.com/tools/http3-test

fb03 4y ago

Nginx is a superb piece of software but for me it has largely been superseded by Caddy. I like it for its sane defaults, you get most things working from the get go and a fairly high score on the 'rate your webserver security' checkers.

folkrav 4y ago
I seem to remember Caddy having some features behind a rather restrictive license - or something like that, my memory is failing me - that made me not consider it at all. But it's been a while, easily a handful of years, and looking at it right now, it looks like they changed that. Seems to be all open-source/Apache 2.0 licensed. Am I crazy or did they really change the licensing situation? Cause it definitely looks pretty interesting, looking at current docs. Edit: Found it - they did switch to Apache 2.0, remove all usage restrictions and open-sourced it all https://github.com/caddyserver/caddy/issues/2786 https://github.com/caddyserver/caddy/issues/2786
- ben_jones 4y ago
  I sympathize a lot with the licensing story of Caddy. /u/mholt has been a very active maintainer and participant in the larger Go community and has every right to create a commercial side to the project and receive compensation for their work. But licensing is hard. AWS abused the leniency of Elasticsearch's original OSS license, so now the industry is set back 10 years with new entrants trying to find the balance between inviting community participation and getting gob smacked by big corporate interests. Im not saying Elastic.co is an angel but its a lesson OSS projects have to take to heart, unfortunately. Thanks Amazon.
  - djhaskin987 4y ago
    I think my favorite reaction to Amazon's aggression is Grafana Labs. They released their code under Affero GPL but let you use a different license if you pay them. Sort of like a new version of the Qt model.
    - 4y ago

ramesh31 4y ago

It’s kind of hard to explain what a big deal NGINX/fastcgi was back in the day coming from httpd/mod_php. All of the sudden, a basic EC2 instance could handle orders of magnitude more concurrent requests. Before NodeJS was a thing, it opened up whole new possibilities for my company at the time. Not sure what my point is. But NGNIX has a special place in my developer heart and it’s really encouraging to hear this.

ggm 4y ago
I am probably in the dying cohort who were mod_python, didn't make uplift to fastcgi and are somewhat mentally stuck in expectation of apache hooks and thin paralellism in our code. The fastcgi thing was true: I don't for a minute deny what you are saying. But it also stranded some "less agile" minds like me. I know significant sites using Perl use::CGI; still.
thriftwy 4y ago
Before nginx there was mod_accel for Apache which was hard to configure but provided same ballpark of performance reverse proxying. Earlier work of the same artist.
jwmoz 4y ago
I came from the same place, you're right, it felt like this super new hacker fast thing.
xorcist 4y ago
The big deal was FPM, the PHP FastCGI process manager. Apache had mod_fastcgi for half a decade before nginx even existed, and then got mod_fcgi, but it was not much good without any support from PHP (which was an even bigger deal back then).
BirAdam 4y ago
You can use Apache with FPM. However, Nginx was definitely what I chose to use. I was working in managed webhosting at the time, and it was just amazing how much could be done in Nginx without needing to track down some abandoned module like had to be done with Apache all the time.

cypres 4y ago

As long as Dynamic Configuration is locked behind an nginx plus-only API, these are hollow words. This is a must have feature for todays workloads (kubernetes or just very busy webservers) in production, and nginx will likely continue to lose market share to Envoy based alternatives where everything is configured through APIs, without needing to reload the server.

kungfufrog 4y ago
This is definitely addressed in the article. The relevant bits talk about moving features from the commercial version to the open source version, as well as the introduction of an open source nginx agent that can do the "dynamic config" on your behalf (via API I presume). I agree with your sentiment though! I hope they do follow through as nginx is generally an easy sell to others when trying to fill holes in your tech stack and otherwise pretty bulletproof.
- cypres 4y ago
  Good catch! I hope this is applicable to the kubernetes ingress controller.
  - bithavoc 4y ago
    yeah, hopefully it helps replace a bunch of lua code from ingress-nginx
  - throwaway892238 4y ago
    Kubernetes will probably drop Ingress in favor of API Gateway in two years.
    - harpratap 4y ago
      That's just the API layer for configuration, you still need a proxy to route. Nginx will still stay relevant
deleted 4y ago
[deleted]

jarym 4y ago

I love nginx and while I use Caddy on my laptop all my servers are nginx. Now the dynamic configuration API is going open this will give Envoy a good run for its money. The big thing Envoy doesn’t do is static file serving and for smaller (anything but the largest…) deployments Nginx makes a ton more sense.

harpratap 4y ago
> Now the dynamic configuration API is going open this will give Envoy a good run for its money Wasn't dynamic configuration always available through OpenResty? It's based on Nginx too with extra Lua modules to fill the feature gaps
mholt 4y ago
What's keeping you from using Caddy in production? We designed it for that too :D PS. Have you seen Caddy's on-line config API? https://caddyserver.com/docs/api https://caddyserver.com/docs/api
- derefr 4y ago
  Global rate-limiting bucketed by Basic-Auth-presented API key? Easy enough in Nginx; no idea how to do it with Caddy. When people say "production", they mean things like "QoS for a shared-multitenant system, in the presence of customers with really badly tuned and spiky request workloads, whose traffic you must nevertheless mostly accept."
  - mholt 4y ago
    If you can't already do it with the rate limit module I wrote, open an issue with your detailed requirements: https://github.com/mholt/caddy-ratelimit https://github.com/mholt/caddy-ratelimit -- should be pretty straightforward for the most part. > QoS for a shared-multitenant system, in the presence of customers with really badly tuned and spiky request workloads, whose traffic you must nevertheless mostly accept. Yah, we see that sometimes. Caddy usually handles it fine, sometimes with a bit of massaging the config.

lewisl9029 4y ago

This article came at an interesting timing for me, since I recently started to explore building my own CDN clusters on top of NGINX open source inspired by this article from Fly: https://fly.io/blog/the-5-hour-content-delivery-network/ https://fly.io/blog/the-5-hour-content-delivery-network/ I've worked with nginx in the past, and didn't have a great experience, so I was apprehensive diving in, but this time was very different. I think njs (their custom JS scripting environment) was a game changer. Support is built in to nginx core, and available by default in their docker containers, so it's much easier to get started with than Lua scripting. Their JS feature support has some quirks (no optional chaining, array destructuring, console.log's don't show up in logs, are some examples of things that threw me off) but overall nothing that blocked me from implementing the functionality I needed, and the integration points within the nginx config felt a lot more natural than I remember with Lua modules. I did run into a number of things that were locked behind their commercial offering that made me a bit uncomfortable betting on it for the long term compared to purely open source alternatives. Off the top of my head: - DNS discovery. There's a thread on the Fly example repo accompanying the blog post that describes the use case and proposes some workarounds: https://github.com/fly-apps/nginx-cluster/issues/2 https://github.com/fly-apps/nginx-cluster/issues/2. Life would be a lot simpler if DNS discovery from the commercial offering was just available (i.e. we can outright delete a brittle bash script that makes DNS queries and reloads nginx on a 5 second interval). This was mentioned in the article as something they're planning to open source. - Access to some kind of shared key-value store for custom caching logic in njs scripts. With Lua we could just connect to Redis, but njs can't seem to establish persistent network connections for now, so that's off the table. This wasn't mentioned in the article, but they did mention in this Github issue that they're planning on open sourcing their keyval module for this use case: https://github.com/nginx/njs/issues/437 https://github.com/nginx/njs/issues/437. I have some use cases where being able to connect to Redis would be ideal, since I'm already using Redis for caching across a bunch of other services, and syncing keyval across a cluster seems to be eventually consistent (https://docs.nginx.com/nginx/admin-guide/high-availability/zone_sync/ https://docs.nginx.com/nginx/admin-guide/high-availability/z...), but for most of my caching use cases it should be sufficient. So this article, along with their overall willingness to work with the community to identify and bring commercial features into open source (at least from what I've observed across their responses to Github issues) does a lot to alleviate those concerns. Though at the end of the day, I don't necessarily need every nginx feature to be in open source. I have no problems with paying for great software like nginx to support its development. But as a small bootstrapped founder, their current pricing structure (from what I could gather on the internet is ~ 2k-5k per running instance) is completely prohibitive. It'd probably require a revamp to the way they sell the software (i.e. self-serve onboarding and automatic license provisioning for smaller customers instead of having customers of all sizes go through expensive sales people), but I'd love to see a more progressive pricing structure with a lower barrier to entry for their commercial product.

nimbius 4y ago

note that this is nginx.com, the division of F5 networks that was purchased largely to staunch the bleeding from nginx, lvs, haproxy and other open source load balancers. the purchase was made in the same faith as oracles acquisition of mysql, albeit with less implosion so far. "part of f5" is written on the logo in almost imperceptible font, that it may evade the PTSD of managers familiar with f5 licenses.

XorNot 4y ago

The problem with nginx commercial was it didn't work with the actual resources developers can bring to bare. If an nginx commercial license solves a problem, and the answer is "great, $5000 a year please" then the developer can't take that to their manager - the problem isn't critical yet, may not become critical, and they'll be asked to look for any other solution to work around it (I've been the guy doing this). A per node, per core, per something license at a much lower rate would've saved them a lot of problems. Because $5 a month per node might get expensive quickly when scaling up, but thats a simple expense I can throw on the corporate credit card and then go "look, now the project is delivered".

porker 4y ago
A 1000x this. I see it with other software companies chasing enterprises (or at least VC backed companies) - Varnish Cache is a particularly egregious example. In the end it hurts them because a developer or consultant may find a problem that is worth the license fee to solve - but with no hands on experience of the product due to the cost, it's hard to recommend it and take the reputational risk in case it doesn't live up to its promises.
karussell 4y ago
Yes, they really miss the opportunity to get a foot into many smaller companies and scale up. For anything useful you need at least $10k/year (likely more), but what if you only need a tiny feature in addition to the open source software? Then this pricing feels just too much (although they of course have to financially support the open source software too) and it'll be very likely that you try to solve it with the open source nginx. If they have modules - why not sell these modules and attach a "reasonable" price to it?

moderation 4y ago

Exactly one year ago the same author published a blog post - "NGINX Sprint 2.0: Clear Vision, Fresh Code, New Commitments to Open Source" [0] It would be interesting to scorecard the progress made on promises made then. There is a lot of repetition. Feels a little hollow. 0. https://www.nginx.com/blog/nginx-sprint-2-0-clear-vision-fresh-code-new-commitments-to-open-source/ https://www.nginx.com/blog/nginx-sprint-2-0-clear-vision-fre...

deleted 4y ago
[deleted]

andrewstuart 4y ago

I used nginx for a very, very long time but abandoned it. I switched to Caddy because I just got so sick of the constant pain of certificates. Caddy does certificates automatically. I also was sick of the complexity of nginx configuration. I could get the things done that I needed to do but it was always painful and time consuming. I've worked out how to do in Caddy everything that I did in nginx though that took alot of time and effort, but I tend to create quite sophisticated web server configs. At this stage there's nothing really that nginx could offer that would bring me back from Caddy.

steve_taylor 4y ago
I’m the same. I’m able to host unlimited subdomains using wildcard TLS and unlimited apex domains using TLS on-demand, all from one Caddy config. It’s amazing. No disrespect to the good people behind nginx. Caddy is simply part of a new generation of web servers.
- mrweasel 4y ago
  > Caddy is simply part of a new generation of web servers. I feel old now, as I continue to deploy Apache :-)
  - 1letterunixname 4y ago
    It's cool as long as you compile in mod_perl, use --with-mpm=prefork, set LC_ALL=C, and use /bin/csh. ;P
  - lsofzz 4y ago
    > I feel old now, as I continue to deploy Apache :-) we wrote bash scripts backends. don't worry about being old. keep going ;) some even had their cgi code running in kernel.. all the more reason to be merrier.
vbezhenar 4y ago
One pain point with caddy for me was cloudflare dns validation. I had to rebuild caddy from scratch, build my own container image. This process is slow as hell and very RAM-intensive, I had to add swap just for it. I wish they publish images with popular plugins built-in.

philsnow 4y ago

I don't know much of the history or politics. I've mostly been a "let's just use (open source, if it needs to be said out loud) nginx" fire-and-forget kind of dude for a while now because I mostly don't care about this layer... > We realize it complicated matters when we created [...] an open source Ingress controller for Kubernetes, [...] different from the community Ingress solution (also built on NGINX). > It’s pretty clear that the Gateway API is going to take the place of the Ingress controller in the Kubernetes architecture. So we [...] will make the NGINX Kubernetes Gateway – which will be offered only as an open source product[...] ... but these two bits very much give me a feeling like they're planting their flag here and offering an open source version so that there's no "need" to go making another one that they don't control.

thinkmassive 4y ago
I think you hit the nail on the head! Here’s a summary (from F5 Nginx) of the key difference between nginxinc/kubernetes-ingress and kubernetes/ingress-nginx: https://github.com/nginxinc/kubernetes-ingress/blob/main/docs/content/intro/nginx-ingress-controllers.md https://github.com/nginxinc/kubernetes-ingress/blob/main/doc...

preisschild 4y ago

I love the OpenResty nginx distribution (which is used by the official Kubernetes ingress-nginx). Makes most of the things you'd have to pay for with the normal nginx free.

synthmeat 4y ago
OpenResty with Redis on the same system - both Lua-powered - is a god-like power. Ability to do basically control and rewrite all your ingress AND egress and have some state via Redis over UNIX sockets. What's not to love? After all, it's what powers the bulk of internet. Granted, it sounds dreamier than it is, since a lot of the contraptions you could come up with might be better placed at application layer. But having operational ability to do these things ad-hoc, security advantages of manipulating at your own infra edge or performance boosts, sure does come in handy!
- lsofzz 4y ago
  We did this on production (still runs at webscale) but we abandoned dev effort on it for ${reasons}. I _loved_ it though :) Hook Lua on the HTTP event processing stages and add icing on the cake with Lua modules to hand-off non-trivial stuffs..

emersion 4y ago

Heading: "Open Source Roots" What it actually means: "As part of this commitment to modernize, we are adding an NGINX Community channel on Slack" Oh right. It completely makes sense that open source roots involve a proprietary communication platform.

matthewmacleod 4y ago
Stop being silly; these are totally orthogonal concerns.
- ddevault 4y ago
  "Stop being silly" is not a polite way to engage in a discourse. These choices matter. https://drewdevault.com/2022/03/29/free-software-free-infrastructure.html https://drewdevault.com/2022/03/29/free-software-free-infras...
lawgimenez 4y ago
Not really a fan of communities siloed into the Slacks or Discords. The only community I enjoyed was either in Stackoverflow chat or Google groups.
tristan957 4y ago
Yep. Electron uses Discord, and any time I want to interact with Electron developers on that platform, I remember that I hate Discord, and I don't care enough to actually open the application to send the message. Using Matrix would definitely be preferred for me since I have Element/Fractal open all day, everyday.
- rs_rs_rs_rs_rs 4y ago
  You can use Discord in your browser, no need to install and open an application on your desktop.
  - tristan957 4y ago

eric4smith 4y ago

Nginx is missing automated TLS services. That’s the main reason we no longer use it for our multi-tenant SaaS systems. Otherwise… it’s great.

eric4smith 4y ago

Nginx is missing automated TLS services. That’s the main reason we no longer use it for our multi-tenant SaaS systems. Caddy powers our thousands of domains - although I will never be a fan of its JSON config file option, it works very very well for us. Otherwise… it’s great.

mholt 4y ago
Thanks for the feedback! What's your site/company?
- eric4smith 4y ago
  Https://www.travelagencytribes.com
francislavoie 4y ago
> although I will never be a fan of its JSON config file option Well, if you use a Caddyfile, the JSON config is just an implementation detail. That decision shouldn't matter to you. The fact is, JSON is the best option for Caddy _at runtime_ to manage its config in memory, especially because Go has first-class support for unmarshaling JSON documents onto a tree of structs.
- eric4smith 4y ago
  I love and use JSON every day. I just don't philosophically believe that it's the right thing for configuration. Too much scope for making errors if done by hand. And also if not doing it by hand, it means additional tooling to create the JSON file. Another layer to deal with with so many layers already. Also Go's first class support for JSON is not a reason for supporting JSON in configuration files. Pretty much every language supports JSON anyway, so whether it's "first class" or "second class" does not really matter. Anyway, we love and use Caddy here. We just don't use the JSON config file.

bayesian_horse 4y ago

A pain point with nginx: NTLM authentication But then again, that seems painful in any scenario.

soheil 4y ago

> Our users have done some pretty amazing things, everything from innovative cache purging Reminds of the days that Varnish + Apache was a thing and you had to invalidate cache more or less manually.

soheil 4y ago

> three words: modernize, optimize, and extend. We intend to make sure these are not just business buzzwords Why does everything have to be modernized? Nginx is awesome not because it tried to keep up with the ilks of ill-thought servers that came and went faster than a flash in the pan. No let’s not put it on GitHub and have every literal person contribute. Elegant architectures and code like this don’t just happen because someone “modernized”.

perlgeek 4y ago

> A quiet but incredibly innovative corner of the NGINX universe is NGINX JavaScript (njs), which enables developers to integrate JavaScript code into the event‑processing model of the NGINX HTTP and TCP/UDP (Stream) modules and extend NGINX configuration syntax to implement sophisticated capabilities. That sounds pretty similar (in spirit, at least) to mod_perl etc. in Apache. Does anybody happen to know a writeup that compares the two?

excitom 4y ago
NGINX has a perl module dating back to the early days, very much like Apache mod_perl. The njs module just gives you a more modern language option.

iknownothow 4y ago

I am an Nginx user and I really do not want to go away from here. It's too performant and too mature. It has a terrible UI problem. I don't want to learn a new tool. All I ask is a Caddy style JSON configuration format for Nginx. And don't just implement some random JSON schema either, please create a well designed schema that is extensible. Take Prometheus [1] or Alertmanager [2] as examples of well designed and extensible schemas. Just give me some basic features first, easy HTTPS, easy reverse proxy, easy rate limiting. You can release the rest of the advanced features in your own time. [1] https://prometheus.io/docs/prometheus/latest/configuration/configuration/ https://prometheus.io/docs/prometheus/latest/configuration/c... [2] https://prometheus.io/docs/alerting/latest/configuration/ https://prometheus.io/docs/alerting/latest/configuration/

mholt 4y ago
Did you know Caddy lets you use an NGINX config? https://caddyserver.com/docs/config-adapters https://caddyserver.com/docs/config-adapters -- no need to "learn" another tool (except for a command or two, perhaps).

yalogin 4y ago

I don’t follow nginx so what I say might not mean much, but this is a weird read for me. It reads hollow, like a PR document but at the same time also feels abut like trying to make amends to the open source world but fails at that a bit. Was there some history here where nginx the company did wrong by the community or was the community aggrieved with nginx? Something happened for sure. Also they should have stayed away from erstwhile Ballmer phrases like “open source is not production ready”, who thinks that way? Tells me that this is not written by someone that contributes or understands open source at all.

pachico 4y ago

If they just offered a decent Prometheus exporter rather than the shitty one that comes with the free version...

lsofzz 4y ago

this is NGINX Inc. talking. grain of salt.

lsofzz 4y ago

Run Kubernetes. Install the open-source Kubernetes ingress controller with your favourite load balancer. I'd wager that'd solve majority of your use cases.

lsofzz 4y ago

manishsharan 4y ago

Is there any plan to port the dynamic configuration capability of Nginx+ to plain old Nginx? https://clouddocs.f5.com/training/community/nginx/html/class1/module3/lab2.html https://clouddocs.f5.com/training/community/nginx/html/class...