It's been an interesting ride the past few years as a software engineering manager: many junior engineers have never developed or deployed anything that requires Apache httpd.
Some have never even heard of it, or seen it in the wild.
EVERY page (or site) seems to need a full blown NodeJS server install and tons of React/Vue etc.
Younger folks are blown away at how quickly I can develop a fully functional site with just Flask, good ole' HTML, basic CSS and VanillaJS using only a couple flat files as a backend database.
I could make a similar argument about complex Python or Golang scripts that are basically the equivalent of multiple bash commands piped into a one liner.
The toolchains to build and deploy a completely static site today are about 10x more complex than a fully dynamic python/ruby/php site a decade or two ago.
Templating engines are far less powerful and extensible than client side frameworks.
FWIW, there are many JS templating engines as well that work with NodeJS too. There are pretty obvious downsides to templating engines that libraries like React and Vue improve upon.
Using flat files as a backend database is great, but not scalable. Does everything need to scale, not always, but it's a lot nicer to have that option and to build it that way from the beginning. It's also ridiculously easy to do so today.
You'd probably be blown away how quickly someone can get a full stack website set up complete with user authentication/accounts management (including reset flows, magic links etc), database integration, front end system, CMS, component design system, and any other goodies.
All this is easily doable in relatively short amounts of time, and makes working with other teams - designers, product owners, marketing teams - so much easier.
Not to mention being able to do everything in a single language. That's a huge win. Engineers can hop around easily and have access to the same dependency management system, language features, etc.
I work with Node and Python regularly and I'm unclear on how a Node stack would be more complex than a Python stack. Isn't "just Flask," which is Python plus packages, equivalent to Node plus packages, both in terms of development and deployment?
I've not touched any standalone web-server like Apache, nginx over past two years for my web applications because Go's built-in HTTP server is production ready. It's one of my favorite reasons to develop in Go and makes portable deployment a breeze.
Lesser number of software to run on the server has resulted in predictable performance and larger savings on cloud costs.
Well… I was a bit surprised to find a Teams group about VMS application support in my company… perhaps I shouldn’t.
After all, we also have a lot of IBM mainframes being used too and, most likely, other exotic stuff in areas I don’t even know about that exist way above my security clearance.
You linked to the French version of this page instead of the English version. Since this page itself isn't translated yet, you don't notice on it, but if you click any of the links on it, you'll end up on pages that actually are French.
I’ve always had a soft spot for Apache httpd, Something about it’s configuration syntax i can grok a little easier than Nginx. I look forward to testing 2.6 out!
Looking at the release docs it’s a smallish release. But I’m very happy something is still going on there. HTTPD has been my go to web server for years and I had used it so many times in production as a proxy/gateway. Always reliable.
I know that everyone uses nginx now and that in the end it has more scalable - event based architecture. But for my scale httpd was never a bottleneck.
It’s just like an “old friend” you can always rely on.
kind of weird to see this posted -- it's not a release announcement. Just some change notes from trunk (you can see on the page it's still versioned 2.5)
It does look like they've added a few nice little features (i wonder if per listen options means we'd be able to listen on a unix socket?)
Apache has shipped with an event-based backend for many years now, so in terms of architecture it's on par with Nginx (while still supporting the classic pre-forking).
Personally I've found apache is more fully featured for niche use cases. For example you can do client cert authentication, then further look up a username from the certificate in ldap for authorisation - all from your apache configuration. For Nginx many of these niche use cases seem to be gated behind Nginx Plus.
One feature of Apache which Nginx annoyingly lacks is HTTP CONNECT support (there is a third-party module from Alibaba which implements it, but it only supports HTTP 1.x).
I've used Apache for over 20 years and I'm going to give you a feature it's missing: request coalescing.
My servers mostly proxy requests to a backend (PHP-FPM, but this is applicable to all other server-side languages). If m requests come in for /foo and all requests have the same cookies, Apache will pass all m requests through to the backend.
With Apache I have to put other software in front of the web server (Varnish usually) that does this for me. So switching to a server where I can reduce installs to support by 50% is appealing.
I've stuck with Apache given it is what I know, having used it for over 15 years. Despite its flaws, it does the job pretty well. I'm also more confident that Apache's code is more battle tested. On top of that I disable all the modules I don't need so my attack surface is pretty small. I run a static site so I basically run Apache with only a few of its core modules. I've tried others (especially Caddy) and while I appreciate some of the enhancements, they don't really add any significant improvements for my use cases.
That really helped me once when I needed to try something using Chez Scheme which doesn't provide network connectivity out of the box. No problem with CGI, though.
Readit News
Some have never even heard of it, or seen it in the wild.
EVERY page (or site) seems to need a full blown NodeJS server install and tons of React/Vue etc.
Younger folks are blown away at how quickly I can develop a fully functional site with just Flask, good ole' HTML, basic CSS and VanillaJS using only a couple flat files as a backend database.
I could make a similar argument about complex Python or Golang scripts that are basically the equivalent of multiple bash commands piped into a one liner.
I genuinely don’t understand it.
FWIW, there are many JS templating engines as well that work with NodeJS too. There are pretty obvious downsides to templating engines that libraries like React and Vue improve upon.
Using flat files as a backend database is great, but not scalable. Does everything need to scale, not always, but it's a lot nicer to have that option and to build it that way from the beginning. It's also ridiculously easy to do so today.
You'd probably be blown away how quickly someone can get a full stack website set up complete with user authentication/accounts management (including reset flows, magic links etc), database integration, front end system, CMS, component design system, and any other goodies.
All this is easily doable in relatively short amounts of time, and makes working with other teams - designers, product owners, marketing teams - so much easier.
Not to mention being able to do everything in a single language. That's a huge win. Engineers can hop around easily and have access to the same dependency management system, language features, etc.
what file formats in particular?
Lesser number of software to run on the server has resulted in predictable performance and larger savings on cloud costs.
For me the reason to use nginx is ease of configuration. Recreating that kind of configuration in code is possible, but tedious and time-consuming.
After all, we also have a lot of IBM mainframes being used too and, most likely, other exotic stuff in areas I don’t even know about that exist way above my security clearance.
I know that everyone uses nginx now and that in the end it has more scalable - event based architecture. But for my scale httpd was never a bottleneck.
It’s just like an “old friend” you can always rely on.
It does look like they've added a few nice little features (i wonder if per listen options means we'd be able to listen on a unix socket?)
* https://httpd.apache.org/docs/trunk/en/new_features_2_6.html
Or just:
* https://httpd.apache.org/docs/trunk/new_features_2_6.html
The Apache httpd project uses even/odd versioning, much like the Linux kernel. 2.5 is the development branch for 2.6.
Personally I've found apache is more fully featured for niche use cases. For example you can do client cert authentication, then further look up a username from the certificate in ldap for authorisation - all from your apache configuration. For Nginx many of these niche use cases seem to be gated behind Nginx Plus.
2.) Sticky Sessions (and various other features) without having to pay $$$ to F5
I end up reaching for Nginx before Apache these days, but I have a lot of production that uses Apache.
My servers mostly proxy requests to a backend (PHP-FPM, but this is applicable to all other server-side languages). If m requests come in for /foo and all requests have the same cookies, Apache will pass all m requests through to the backend.
nginx instead will pass one request to the backend and then serve the response to all m requesters, reducing backend load. The setting is called proxy_cache_lock (https://nginx.org/en/docs/http/ngx_http_proxy_module.html#pr...)
With Apache I have to put other software in front of the web server (Varnish usually) that does this for me. So switching to a server where I can reduce installs to support by 50% is appealing.
Oh god, it didn’t have SHA-256 support before today? Was it using MD5 and SHA-1?
I knew basic auth was weak but jeez.