[swift-server-dev] Next HTTP API meeting

[Michael Chiu]

Personally I always prefer protocol over value/reference type because I do think it enable end users to write safer code and increase the freedom of the use of the framework.

> On Mar 27, 2017, at 7:08 AM, Logan Wright <logan at qutheory.io> wrote:
> 
> For expectations, my comments about it are mostly gathered from conversations and bug help and question answering from users greatly confused by value types. Unfortunately, many of these conversations are lost to the free plan associated with slack. Aside from expectations (which as Paolo pointed out could use more evidence) reference types provide more performance, reduce bugs, and reduce code overhead which seem like pretty good reasons to me. 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? Right now, that seems to be the only pro that value types propose since there's no other tangible advantage that I can see.
> 
> - Logan

Just a quick example for 2 value type use case .

Case 1) able to reuse static, pre-constructed response

// static 
let httpDefaultErrorResponse = HTTPRespone(status: 404, headers: […omit…], body: nil)

func response_to_some_request(req: HTTPRequest, res: inout HTTPResponse) {
… omit code ..
If resource.notFound {
	res = httpDefaultErrorResponse.appendBody(“\(resources.uri) not found”)
}
… omit ...
}

Case 2) a simple server receive response from 1 end point and forward to different clients with appended header.

…omit...
var common_response = my_discrete_computing_server.makeCommonResponse(from: discrete_computing_request )
pool.clients.forEach {
	client.send(common_response.appendHeader($0.workerId, for: “worker-id”)
}

> On Mon, Mar 27, 2017, 10:31 Tanner Nelson via swift-server-dev <swift-server-dev at swift.org <mailto:swift-server-dev at swift.org>> wrote:
> 
> I did a quick test of inout struct vs. class performance. The code can be found here: https://github.com/tanner0101/request-types <https://github.com/tanner0101/request-types>
> 
> I found only a marginal increase in performance (~5%) in favor of inout value types. https://github.com/tanner0101/request-types/issues/1 <https://github.com/tanner0101/request-types/issues/1>
> 
> Additionally, non-inout value types were a lot slower. This is obvious to the seasoned Swift dev considering each middleware in the test modifies and thus must copy the request. But this is the exact type of performance issue you can expect developers to create when interacting with "non-obvious value types". HTTP request/response being non-obvious value types compared to something like an integer or a float. (I'd argue the majority of web developers would expect request/response to be a reference type and thus easily forget or not know to use `inout`)

Thanks so much for the benchmark result, this is definitely a helpful reference for future discussion. The thing I concern is, the performance of reference type is likely going to decrease proportion to the number of connections due to heap allocation.

Michael

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20170327/f76f1bf0/attachment.html>