I think a stand alone http parser is still necessary, simply because it is a fundamental building block for most web frameworks nowadays.
1. Compatibility
I’m not sure about other people, but when I write a web framework I will assume people who use my framework are not necessary have nginx and apache installed. And someone eventually, like I did, will probably want to build a fronted web server as well, in that case, having a standalone will make things a lot easier.
2. Reverse-Proxy
Some applications are using frontend server such nginx as a reverse-proxy server and proxy over unix domain socket (for example, node.js). In that case, even with a frontend web server, a http parser is still necessary.
3. Optimization
If someone eventually written a web framework that are subject to use within a private network only, let’s say a computational hub, and somehow they decide to use HTTP, totally rely on frontend server will make a lot of optimization impossible.
For example the sendfile() system call. If an application has the ability to generate http header, it can easily optimize the performance of the server when serving file-related-content by using sendfile(), or TCP_CORK + sendfile() in linux, and also a lot of TCP related optimization. This just cannot done by using a frontend server.
Michael
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
···
Le 26 oct. 2016 à 10:59, Brent Royal-Gordon <brent at architechies.com <https://lists.swift.org/mailman/listinfo/swift-server-dev>> a écrit :