[jebblue]

One of the problems with application servers is like well, port separation, process isolation, when a change to the context is desired but it might affect all the apps you have to be very careful. Having your web app be its _own_ app is hugely advantageous.

[twic]

You can, and usually do, do exactly that with app servers.

It's true that app servers were originally conceived as a way of hosting multiple apps in a single JVM, but it quickly became apparent that this was a terrible idea, and nobody does it. You run one instance of the app server per app. The app server is really just a great big bundle of useful libraries and a web framework.

[jshen]

so why separate the two if there is always 1 app per app server?

[twic]

(I'm guessing that was "So why separate ...", and you've just had root canal)

They're separated in the sense that the app server is something you download that exposes an API, and the app is something you write on top of the API. It's much the same as the way the JVM and the class files are separated, or the way the OS and the JVM are separated. It's a fairly straightforward, pragmatic application of layering.

[jshen]

Maybe we mean different things by "separated". I want the app server bundled into the app, not an assumed dependency that the app has on the target environment.

Rack in the ruby world exposes an API that ruby web apps build on top of, but you never install an app server then install your app into the server.

[twic]

Aha, yes, that makes sense. I don't think there's anything fundamentally wrong with packaging the app server along with the app. It's just not traditional in the Java world.

My preferred solution would be to package the app and the app server as operating system packages, and have the app depend on the app server. That makes the dependency explicit, but doesn't leave you with a gigantic deployable.

[jshen]

Here is one reason I like the bundled approach. I've been using golang recently which compiles into a machine executable. I was building a REST API that many third parties would use. When they wanted to use the API for development all I had to do was send them the bundle and tell them how to start. There were no other dependencies at all. It didn't assume a particular package manager, OS, or anything else. Take this file and execute it, that's it.

[haddr]

this in general leads to an even worse practice: creating one huge standalone app instead of several specialized web apps. when you develop a service with an embedded server, your endpoint will have an unique port (as each app will have to allocate its own unique port number) and all the idea of restful URI gets broken.

[jshen]

You lost me. How does embedding the app server break URIs?

[haddr]

in the embedded mode you have one application server per app, so you have one app at port 80, another at 81, etc... so you can't just have a nice URL pattern for your applications, becase each one will have different port number. Unless you set up additional reverse proxy...

[jshen]

you put nginx in front of it, which you should do anyways for most things.