In case you are honestly interested--although your hyperbole suggests otherwise--an app server then was what the docker daemon (or podman or other container launcher) would be now. The two most common in my career were JBoss and Tomcat. Since Java packaged applications into Jars which could be run anywhere (up to environmental assumptions made by developers), you could simply scale up by sending these jars to the app servers to run. Actually, the Alibaba group was quite annoyed in the JCP that western members had given up on these aspects of the Java platform and were moving to support containerization. Arguably, CGI servers for php/python etc. were also a type of app server, although I rarely heard them referred to as such. App servers standardize what it means to start an application which makes operating many applications much easier.
Message buses were generally in memory or in process streaming brokers. Most of these have moved externally today via Kafka, RabbitMQ or cloud proprietary versions like SQS. Some people may lean on ZeroMQ to build similar behaviors when doing multiprocessing and some people may even do it in process if they like the api. Definitely very much part of large scale application development today although the terms of art have changed.
Dependency injection is just a fancy name for polymorphism via fields in your struct, although if you have too much exposure to spring you will associate it with that plus an inversion of control on the actual injection part: that is, you will associate it with heavy use of annotations. If you have polymorphism with a switch (or chained ifs) on a parameter, you don't have dependency injection but if you have polymorphism by having different inplementations of a field of your struct then you are doing dependency injection. Very much part of good software design today, the annotation driven wiring possibly not so common outside of Java + Spring.
I think of dependency injection as a generalization of LD_PRELOAD, the point being that the "injection" is done via configuration that is external to the application's code.
That's a good take, I hadn't really thought of that one before and I had certainly used LD_PRELOAD or some incarnation thereof (forgive my memory is was more than a decade ago) to swap out different implementations of the same API.
> In case you are honestly interested--although your hyperbole suggests otherwise--an app server then was what the docker daemon (or podman or other container launcher) would be now.
Sure. I have worked on JVMs before, but not server side, and I never had to touch anything sold by IBM.
> Arguably, CGI servers for php/python etc. were also a type of app server, although I rarely heard them referred to as such.
No, I think there's a difference. The deployment story for PHP was that you copied it to the web server and that was that. The mandatory part was a webserver you had anyway. There is FastCGI, but in PHP's case it can be thought of as purely a cache and is not necessary.
> App servers standardize what it means to start an application which makes operating many applications much easier.
A PHP web app does have some moving parts like needing to start nginx/fastcgi/mysql, so in that sense it still needs a container.
But the difference between the PHP source itself and Java is that PHP is 1. stateless and 2. doesn't take nearly as long to start up.
The first one is the big one and means you don't need to restart anything to update the app. This part of PHP is so well designed it practically makes up for how bad the rest of it is.
The second one was more of a Java flaw; the runtime is undercooked (which is why it had all that other super complex stuff on top of it) and everything has to go on the heap, instead of having more of a concept of constant data that could just be mapped in from the binary/jar file. That's what they got for not adding value types I guess.
Message buses were generally in memory or in process streaming brokers. Most of these have moved externally today via Kafka, RabbitMQ or cloud proprietary versions like SQS. Some people may lean on ZeroMQ to build similar behaviors when doing multiprocessing and some people may even do it in process if they like the api. Definitely very much part of large scale application development today although the terms of art have changed.
Dependency injection is just a fancy name for polymorphism via fields in your struct, although if you have too much exposure to spring you will associate it with that plus an inversion of control on the actual injection part: that is, you will associate it with heavy use of annotations. If you have polymorphism with a switch (or chained ifs) on a parameter, you don't have dependency injection but if you have polymorphism by having different inplementations of a field of your struct then you are doing dependency injection. Very much part of good software design today, the annotation driven wiring possibly not so common outside of Java + Spring.