> As a relatively young dev, the idea of a "web server" as a standalone binary that serves your application (vs a library that you use to write your own "server

> As a relatively young dev, the idea of a "web server" as a standalone binary that serves your application (vs a library that you use to write your own "server") feels strange. In my eyes, the ideal setup is one that's layered: where you have an ingress that's basically a load balancer that also ensures that you have SSL/TLS certificates, enforces rate limits, perhaps is used for some very basic logging, or can optionally do any URL rewriting that you need. Personally, i think that Caddy (https://caddyserver.com/ https://caddyserver.com/) is lovely for this, whereas some people prefer something like Traefik (https://traefik.io/ https://traefik.io/), though the older software packages like Nginx (https://nginx.org/en/ https://nginx.org/en/) or even Apache (https://www.apache.org/ https://www.apache.org/) are good too, as long as the pattern itself is in place. Then, you may additionally have any sorts of middleware that you need, such as a service mesh for service discovery, or providing internal SSL/TLS - personally Docker Swarm (https://docs.docker.com/engine/swarm/ https://docs.docker.com/engine/swarm/) overlay networks have always been enough for me in this regard, though some people enjoy other solutions, such as Hashicorp Consul (https://www.consul.io/ https://www.consul.io/), or maybe something intended for Kubernetes or other platforms that you already may be using, like Linkerd (https://linkerd.io/ https://linkerd.io/). Finally, you have your actual application with its server. Personally, i think that the web server should be embedded (for example, embedded Tomcat with Spring Boot) or indeed just be a library that's a part of the application executable, as long as you can update it easily enough by rebuilding the application - containers are good for this, but aren't strictly necessary, since sometimes other forms of automation and packaging are also enough. The reason why i believe this, is because i've seen plenty of deployments where that just isn't the case: - attempts to store certificates within the application, each application server having different requirements for the formats to be used, making management (and automation) of renewal a total nightmare - attempts to use external application servers, like a standalone install of Tomcat/TomEE/GlassFish, which are always a pain to manage and integrate with the application, often leading to inconsistent configurations, especially if something like Ansible isn't used - no ability to easily do URL rewriting, whenever you realize that you need to do something a bit differently, or figuring out how to do rate limits or anything of the sort becomes needlessly hard, and even then you can't really protect the app from too much traffic if it is the endpoint for all the requests, especially troublesome if it's also used by other internal services - no observability, since it becomes harder to tell whether there's a problem with the load overall (e.g. load balancer nodes are not keeping up), or the actual server implementation within the application - actually, not having a separate ingress also makes load balancing too hard in many setups, since service meshes simplify this bunches