Where will D sit in the web service space?

Adam D. Ruppe via Digitalmars-d digitalmars-d at puremagic.com
Sun Jul 12 15:10:27 PDT 2015


On Sunday, 12 July 2015 at 20:36:26 UTC, Etienne Cimom wrote:
> For me at least, D has a lot more to offer because with the 
> recent developments in vibe.d

I don't think I'd even use vibe for your use case - you'd never 
need to scale to 10,000 connections if it runs on localhost.

Perhaps a little-known part of my web.d is a few special parts 
for localhost work, including a synchronous javascript bridge 
back to your server side functions.

web.d's normal behavior is to provide web pages and async 
javascript access to your class methods:

D:
class Foo : ApiProvider {
   int add(int a, int b) { return a+b; }
}

Usage from javascript:

Foo.add(1, 2).get(function(sum) { alert(sum); } );

or in the browser, you can navigate to site/add and it presents a 
form asking for a and b, and the submit shows the answer.


But it also has sync JS support:


var sum = Foo.add(1, 2).getSync();


Which is nice because then you have linear flow. The bridge also 
translates D exceptions into JS exceptions here.


You wouldn't normally do that on the web since synchronous events 
can freeze up the browser from network lag. But doing it on 
localhost should be pretty reliable.


cgi.d's underlying threaded implementation is also fine here, as 
it will trivially scale to the small handful of connections you 
need for localhost.... and you can still use your ordinary other 
libraries to handle requests, e.g. C libraries that block, with 
no hassle (heck, you could even make a gui thread pop up a 
regular window to control the server with ease).

> We're already on top and we don't know it yet

I've felt that way for about five years now!


More information about the Digitalmars-d mailing list