Web servers in D

[Hasen Judy]

On Tuesday, 12 September 2017 at 12:34:26 UTC, aberba wrote:
> On Friday, 25 August 2017 at 05:25:09 UTC, Hasen Judy wrote:
>> What libraries are people using to run webservers other than 
>> vibe.d?
>>
>> Don't get me wrong I like the async-io aspect of vibe.d but I 
>> don't like the weird template language and the fact that it 
>> caters to mongo crowd.
>>
>> I think for D to a have good web story it needs to appeal to 
>> serious backend developers, not hipsters who go after fads 
>> (mongodb is a fad, jade/haml is a fad).
>>
>> I probably need to combine several libraries, but the features 
>> I'm looking for are:
>>
>> - Spawn an HTTP server listening on a port, and routing 
>> requests to functions/delegates, without hiding the details of 
>> the http request/response objects (headers, cookies, etc).
>>
>> - Support for websockets
>>
>> - Runs delegates in fibers/coroutines
>>
>> - Basic database connectivity (No "orm" needed; just raw sql).
>>
>> - When iterating the result set of a sql query, has the 
>> ability to automatically map each row against a struct, and 
>> throw if the structure does not match.
>>
>> - More generally, map any arbitrary object (such as json) to a 
>> struct. Something like Zewo/Reflection package for swift[0].
>>
>> [0]: https://github.com/Zewo/Reflection
>>
>> I feel like Vibe.d satisfies my first 3 requirements, but for 
>> the rest I will probably have to look for something else.
>
> In 2017, backend developers are more likely to write 
> microservices which expose rest/graphQL APIs and put them in 
> dockers containers.... Unless you're a full stack developer, 
> you'll not be using jade/diet (at least not enough to be 
> tempted to use something else).
>
> Its still sucks there's no object storage api for D. Are you 
> guys still building monolithic web servers?

Sorry this is an incredibly late response.

Come on now, in CURRENT_YEAR people are jumping and this year's 
fad train. I don't want to jump along, thank you very much.

And I don't understand this containers business. As far as I can 
tell it was designed for interpreted languages because they tend 
to have a lot of very specific dependences that are a hell to 
manage.

If the compiler can produce a statically linked binary, then 
there's no problem that a container would solve here.