[swift-server-dev] Prototype of the discussed HTTP API Spec

[Paulo Faria]

> On the other side people like Paulo (I think ;-) see the API more like
just that, a common AP*Interface*. Only the common API is shared, everyone
still has his own ’server' and eventually code on top of that is shared.
Kinda the other way around.

I see this project as both, a base for all other frameworks based on
libdispatch/libdill/libuv/libwhatever, *AND* a default implementation (based
on libdispatch) with everything up to the HTTP server and client which
people can just import and use for simple use cases. The goal of this
project as far as we conceived it before starting is *NOT* to provide a
high level framework with routers, middleware, etc. So higher level
frameworks like Kitura, Vapor, Perfect, Zewo, etc will always be desired
for more complex applications. At least that's what was discussed by the
core members when we were setting up this work group. Having said that we
just can't ignore the existing higher level frameworks. And when we talk
about synchronous APIs, Johannes point, which I completely agree, is about
the lack of official Swift support for green threads. The problem with that
argument is that green threads aren't the only valid way to use synchronous
APIs.

Vapor, for example, which is one of the most used frameworks nowadays, uses
blocking synchronous APIs over threads. Yes, this is not very performant,
but a whole lot of other extremely popular frameworks written in other
languages are (or were at some point) blocking. The number of people using
Vapor speaks for itself. We just *can't* ignore them. If that concurrency
model is enough for their use case. We just can't simply ignore them.

So, in my view, the ideal would be to support both async and sync APIs, and
the default implementation that we'll provide with this project should be
asynchronous using libdispatch.

Of course we could just say F*@#$ you to all of the other approaches and
only implement a single approach, but I think we can do better than this.

On 1 June 2017 at 17:41, Helge Heß via swift-server-dev <
swift-server-dev at swift.org> wrote:

> Hi,
>
> > On 1. Jun 2017, at 21:07, Johannes Weiss via swift-server-dev <
> swift-server-dev at swift.org> wrote:
> >> I have to admit that I tried to follow the discussion here, but I got
> lost. I do not see what all this asynch/kevent/... stuff has to do with an
> HTTP API.
> >>
> >> Its probably me though. It happens… :-(
> >
> > As one of the main offenders I can tell you that I don't quite
> understand it either.
>
> yes, the discussion drifted off and is a little lost in arguments. But I
> don’t think it is actually hard to understand at all.
>
> There are two main opinions:
> A) there should be a callback based API only (Johannes)
> B) there should be a synchronous API too     (Paulo)
>
> If this effort goes with just A, I think it is kinda obvious that this
> won’t work for frameworks with a synchronous API. Not because it isn’t
> possible to implement it at all (I showed that it is w/ the Apache one),
> but because it isn’t possible to implement in a way which aligns with the
> higher level synchronous APIs of the frameworks (which are not callback
> based and don’t want to be callback based).
>
>
> To resolve the situation one option would be to completely leave out the
> relevant parts and just have the parser, the request/response objects. And
> other stuff working just on top of that (e.g. cookies have been mentioned,
> auth decoding, utility stuff like that).
> Talking API.md:
>
>   https://github.com/modswift/http/blob/develop/API.md
>
> Essentially remove: HTTPBodyHandler, HTTPBodyProcessing, HTTPBodyChunk.
> They could still be used in a Dispatch based default implementation, but
> wouldn’t be ‘standard API’. But add: HTTPParser.
>
>
> I think the *goal* of this group is a little mixed up or maybe unclear. My
> assumption was always that this provides a standard server implementation
> which higher level frameworks can build upon. It wouldn’t do middleware,
> Zope or WebObjects style processing, but it would definitely do all the
> HTTP server stuff. SSL, HTTP/2, eventloop etc. What `httplib` does in
> Python or `http` in Go. The user can just import the Swift module and off
> he goes. It's the standard Swift way to do HTTP servers and it is built in.
> If he then wants fancy HTML templates, an integrated ORM and stuff like
> that, he’d use a framework build on top of that basic lib.
> This IMO definitely implies that an I/O model and all that is chosen for
> the user.
>
> On the other side people like Paulo (I think ;-) see the API more like
> just that, a common AP*Interface*. Only the common API is shared, everyone
> still has his own ’server' and eventually code on top of that is shared.
> Kinda the other way around.
>
> So maybe the common goal should be clarified (or found) one more time. Or
> maybe I’m just completely wrong :-)
>
> hh
>
> P.S.: Some of my personal opinions, just to give some context, no need to
> discuss them at all:
> - It would be great if Swift would have a HttpServer lib which you
>   can just use
> - If such exists it would be only confusing to provide two different
>   APIs (in fact the other approaches may just die adoption wise as
>   the standard, well, sets the standard :-)
> - In general I’m mostly in favour of using async for the standard
>   module (despite what follows)
> - I think that async APIs are overrated. They are a must on very
>   highly scalable systems of certain kinds, but for many many types
>   of deployments they are just not necessary.
> - For most people programming against async APIs is a
>   pain in the **, particularly w/ ARC. It just raises the complexity a
>   lot. (which people then try to solve w/ more additional magic like
>   Promises)
> - Node.js changed that a little, but the far majority of web
>   development is still done in traditional synchronous/threaded
>   setups: WebObjects, PHP, Servlets, Rails. IMO for a good reason,
>   see above.
> - If you use an async API and people end up doing `concat`, which
>   is really common in Node .., you gained, well, nothing.
>
>
> _______________________________________________
> swift-server-dev mailing list
> swift-server-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-server-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20170601/ba3b3f37/attachment.html>