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

[Yoann Gini]

> Le 26 oct. 2016 à 10:59, Brent Royal-Gordon <brent at architechies.com> a écrit :
> 
> 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.

100% agree with that

> 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.

I’m not really sure this is a pros or cons. Having to run multiple processes and use sockets increase code complexity and surface for attacks. It increase the number of services started so the number of processes to watch.

In some scenario, this is better, in some others, this is worst.

As I’ve said on my first e-mail, I don’t say standalone swift HTTP server must not exist. I’ve just said it could be interesting to think about others patterns.

Allowing behavior like WSGI where you can use both scenario is IMHO the best solution ever, so it can fit for all needs. 

Best regards,
Yoann Gini