Why not rely on existing models?


(Yoann Gini) #1

Hi

I’m following Swift server side initiatives really closely. I’m a developer and sys admin, really interested in subjects linked to performance and security.

Swift look like a perfect language for server side, especially with Cocoa framework on the back.

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.

Looking at what currently exists, I found WSGI (or even old school CGI) way more interesting for production purpose.

If we are trying to deploy Swift on the server side, CGI alike solution look like the quick win. It avoid wasting dev time by reusing all HTTP server already existing, so developer from this community will have to concentrate only to create a bridge. And even more, this bridge can be created in the first version by simply porting WSGI behavior to Swift.

This is just a simple personal opinion. Just wondering why.

Best regards,
Yoann Gini


(Brent Royal-Gordon) #2

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.

···

On Oct 26, 2016, at 2:00 AM, Yoann Gini via swift-server-dev <swift-server-dev@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.

--
Brent Royal-Gordon
Architechies


(Helge Heß) #3

Is there a need for a swift-server-users mailing list?

hh


(Yoann Gini) #4

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@architechies.com> a écrit :


(Chris Hanson) #5

Just as a point of history, WebObjects did this in the mid-1990s. The built-in web server was used primarily for development purposes.

WebObjects applications were generally deployed using a different WOAdapter entirely, rather than do something like reverse-proxy the built-in server.

  -- Chris

···

On Oct 26, 2016, at 2:59 AM, Brent Royal-Gordon <brent@architechies.com> wrote:

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


(Yoann Gini) #6

It depends on whether you consider a language is made for the language itself or for production. Considering real case usage scenarios and constraints might be a good idea in any kind of software development.

In particular, advocating for WSGI alike integration isn’t a user consideration but a request for the server side app developers who would like to avoid coming back to the Stone Age of Tomcat.

Best regards,
Yoann Gini

···

Le 26 oct. 2016 à 10:25, Helge Heß via swift-server-dev <swift-server-dev@swift.org> a écrit :

Is there a need for a swift-server-users mailing list?