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.
