[swift-server-dev] Next HTTP API meeting

[Sergo Beruashvili]

Hello everyone,

I think we are missing something here,
If we use struct for Request/Response, this means we cannot use them in @escaping closures.

Most of requests end up reading from a database ( redis, mysql/postgre... ) or maybe even from a network.
Proper way of reading from those sources would be using DispatchIO ( or similar technique ) , which does not block the current execution, but reads the data and calls your @escaping closure once its done.
Swift closures can't capture inout structs.

Regards,
Sergo

> On 27 მარ. 2017, at 22:55, Helge Heß via swift-server-dev <swift-server-dev at swift.org> wrote:
> 
>> On 27 Mar 2017, at 15:30, Tanner Nelson via swift-server-dev <swift-server-dev at swift.org> wrote:
>> Re: performance,
>> 
>> I did a quick test of inout struct vs. class performance. The code can be found here: https://github.com/tanner0101/request-types
> ...
>> Please feel free to submit any prs/issues/comments about ways I could improve this test to make it more accurate. 
> 
> Just the obvious:
> 
> Primarily this lacks an implementation of a CoW backed value type which could avoid thread safe RC and hence be significantly faster.
> 
> Then your test is lacking multiprocessing hence doesn’t show the potential overhead of ARC (CPU cache flushes and such).
> 
> But it is a good starting point. Better than just discussing stuff ;->
> 
> 
> Personally I have no real preference for value vs ref. I think:
> 
> - performance sensitive frameworks will use their own HTTP layer anyways,
>  maybe we shouldn’t focus too much on it. Just try to avoid stupid
>  decisions ;->
> 
> - that web frameworks will wrap the low level request very often, 
>  which means ref-oriented frameworks could easily box a low level 
>  struct in that ref-Request type.
> 
> - a Request is clearly a reference type from a design perspective.
>  That doesn’t imply mutable, all the fields could be let’s except
>  for the body stream.
> 
> - but that a RequestHead as returned by a parser might be a value
>  object
> 
> - I’m a fan of zero-copy and hence think that the thing returned
>  by the parser should be mostly byte block based and specifically
>  only build strings once such are explicitly requested (there are
>  so many headers you never ever touch). But see my first point.
> 
> 
>> On 27 Mar 2017, at 15:51, Swizzlr via swift-server-dev <swift-server-dev at swift.org> wrote:
>> Aren't framework authors essentially failing in their job if they expose the same low level types to end users that the HTTP module will provide? Surely we'd be mutating, copying and rewriting the lower level request and streams into higher level abstractions?
> 
> I don’t think that this is necessarily true. A wrap will be common, but it really depends on the framework and how low or high level the stuff is. For example in WebObjects you had three objects: Request, Response and Context. The latter was the thing it used to track r/r transaction state, R&R themselves have been pretty simple. Node-like stuff pushes a lot of things into the request object itself, whether that is good design is a matter of taste and precisely where web frameworks may differ.
> 
> 
>> On 27 Mar 2017, at 16:08, Logan Wright via swift-server-dev <swift-server-dev at swift.org> wrote:
>> reference types provide more performance, reduce bugs, and reduce code overhead. 
> 
> No offence, but it would be nice to show proof of such claims instead of just repeating such again and again.
> 
> More performance? Even the simple test of Tanner showed that inout-value types are faster, and it doesn’t even pass around a lot of references … Then there may be multiprocessing issues. But OK.
> 
> *Reduce* bugs? I have no idea on how you can arrive at that. There may be some potential in value types reducing bugs, but I’m not completely sold on that either (reference types can be immutable too).
> 
> Reduce code overhead. Not sure what you mean by that, that I don’t have to type `inout`? :-)
> 
> 
>> I think a good question is, can anyone propose a use case where one would want to mutate a request without reflecting those changes to subsequent responder chains?
> 
> Yes, you may want to adjust the request and do an internal redirect, or one to a different service. I can see quite a few use cases for this. But in general I think we are on the same page here, the web-framework level request should conceptually be a ref type. That doesn’t mean the low level type has to be one.
> 
> 
>> Right now, that seems to be the only pro that value types propose since there's no other tangible advantage that I can see.
> 
> IMO two of the pros you state for reference types are more likely pros of value types, certainly no contras. I don’t understand your third.
> 
> 
>> I think protocols are the most flexible way to implement the apis, I also believe that they're most in the spirit of the group which is to create something adaptable to the various frameworks to allow more code share for low level libraries.
> 
> I’m probably pro-protocols. Particularly that it would be very good to have a higher level protocol which represents a request and a response. Just so that not everyone has a different way to access e.g. a header or an own enum for ‘method’.
> 
> But that is something different to the stuff returned by the parser. Of course the parser could also just take a delegate instead of returning a fully parsed ‘Request’ object.
> 
> 
>> On 27 Mar 2017, at 16:42, Tanner Nelson via swift-server-dev <swift-server-dev at swift.org> wrote:
>> @chris in my experience there's been very little passing of request/response between threads.
> 
> That is absolutely true and a reason to avoid ARC over inout or UnsafePointer. I mean, it certainly wouldn’t be a catastrophe and would ruin everything, but well, it is overhead that one may or may not want to avoid :-)
> 
> 
>> On 27 Mar 2017, at 18:12, Chris Bailey via swift-server-dev <swift-server-dev at swift.org> wrote:
>> One of the key goals is to provide the concrete implementation of a utility library for HTTP parsing
> 
> Well said. Someone needs to produce a proposal that can be tried and played with, then we can check whether we need to abstract some types into protocols and demo how that works with higher level frameworks. Outline issues, performance, etc.
> 
> hh
> 
> _______________________________________________
> swift-server-dev mailing list
> swift-server-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-server-dev