Web servers in D

[rikki cattermole]

On 29/11/2017 5:51 AM, Hasen Judy wrote:
> 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.

Containers are an "easy" way to push your full system over to another's 
servers. It is all about cost. They are cheaper than VM's as they 
require less resources to manage and use.