[swift-server-dev] Why not rely on existing models?

Brent Royal-Gordon brent at architechies.com
Wed Oct 26 04:59:23 CDT 2016

> On Oct 26, 2016, at 2:00 AM, Yoann Gini via swift-server-dev <swift-server-dev at swift.org> wrote:
> Looking at all the current initiative, I’ve to say don’t understand something: why everyone start by creating a brand new HTTP server?
> From a DevOps point of view, it looks like a waste of resources to start writing HTTP server framework in swift. No sys admin will ever allow a small custom HTTP server to be open to the Internet without a proxy before. Plus, we already have two really great HTTP servers in the UNIX world, Apache and NGINX. In no way a custom HTTP language related framework can cover as much as those two projects.
> Even if I understand some people might want built-in HTTP handler in a client/server app, I don’t really understand why all existing initiatives take this road.

This trend seems to have started with Rails. It has a few advantages:

1. You can use the embedded server in development and testing. This is *way* easier than installing Apache on your development machine or CI setup and configuring it to point to your application.

2. In production, you can configure Apache or nginx to reverse proxy for the app; this configuration is almost entirely agnostic to the application itself, so you can modify the application's behavior without playing with the frontend web server.

3. The frontend proxy and backend web server communicate over a plain old socket, so they can run as different user accounts or even in separate VMs.

Basically, embedding a web server and reverse proxying for it isolates the application from the frontend server and simplifies the management of both.

Brent Royal-Gordon

More information about the swift-server-dev mailing list