Answers needed from those using D for Web Development, Web APIs and Services

Neia Neutuladh neia at ikeran.org
Sun Dec 24 15:48:56 UTC 2017


On Friday, 15 December 2017 at 08:13:25 UTC, aberba wrote:
> I'm going to do a writeup on the state of D in Web Development, 
> APIs and Services for 2017. I need the perspective of the 
> community too along with my personal experience. Please help 
> out. More details the better.
>
> 0. Since when did you or company start using D in this area?

I have been fooling around with D for web-related stuff for a 
year or so, but nothing terribly concrete. I've been actively 
migrating my RSS system to D mostly in the past month and a bit.

> 1. Do you use a framework? Which one?

I use vibe.d.

> 2. Why that approach and what would have done otherwise?

It was there. Without it, I probably would have looked at Hunt 
briefly and then cobbled together something based on CGI.

> 3. Which task exactly do you use D to accomplish?

https://github.com/dhasenan/pierce/

I use D for all backend code, so:

* reading feeds
* mucking about with the database
* authentication

> 4. Which (dub) packages do you use and for what purpose?

* arsd-official:dom: an excellent HTML/XML parser
* datefmt: date parsing, primarily, with a side of formatting
* pbkdf2: password hashing
* urld: to have consistent URL handling with other applications
* vibe-d-postgresql: postgres

> 5. How do you host your software code (cloud platforms,  vps,  
> PaaS, docker,  Openshift, kubernetes, etc)?

I have a couple VPS boxes with linode that I deploy stuff to.

PaaS providers do me a concern. Docker is

> 6. What are some constraints and problems in using D for such 
> tasks?

vibe.d is all non-blocking IO and it's not always easy to find a 
library that does a thing with non-blocking IO. You can dispatch 
tasks to a worker thread, but that uses D's `shared` system, 
which imposes barriers I'm not terribly familiar with. That also 
doesn't give you Futures.

I believe my code still has blocking database access, at least in 
production. With my user volume (one for the D alpha, three for 
the C# version), this isn't yet a huge problem; however, I've had 
to fork a process for handling background tasks, since they can 
be long.

dub doesn't know how to dynamically link dependencies. This means 
my binary is 38MB and takes half a minute to copy to the server. 
Since I worked out how to do dynamic linking manually, I'm going 
to add that in, and then I'll be able to rsync everything. That 
should reduce my application's binary size to a megabyte or less, 
which will be a lot nicer.

vibe doesn't have a logging appender for std.experimental.logger, 
and vibe's logging system isn't terribly awesome. I wrote a 
vibe-compatible rolling file appender for std.experimental.logger 
in the end. It's kind of weird, though, that 
std.experimental.logger doesn't separate layout from the output 
type. It makes sense for some potential appenders to ignore the 
layout system you would give them -- like if you have an appender 
for some sort of structured logging API that accepts 
protobuf-encoded events. But most logs are just text, and if I 
don't like the layout, I need to write a whole logger.

> 7. What solutions do you recommend?

vibe.d isn't a bad option. It's got a lot of stuff in it. 
However, it might be simpler on the whole to use fastcgi.


More information about the Digitalmars-d mailing list