D Web Services Application Potential?

Etienne via Digitalmars-d digitalmars-d at puremagic.com
Wed Jul 29 10:25:16 PDT 2015


On Wednesday, 29 July 2015 at 16:55:25 UTC, Laeeth Isharc wrote:
> On Wednesday, 29 July 2015 at 13:22:43 UTC, Etienne Cimon wrote:
>> There's a really minimal amount of code on web servers 
>> nowadays with javascript frameworks and databases doing all 
>> the work. I actually use the size of a vibe.d application 
>> (2mb) to my advantage to produce a plugin that will overload 
>> certain requests on the client's computer (via a windows 
>> service or launchd daemon and reverse proxy). This allows much 
>> more extensive use of local resources, which is really 
>> untapped way of developing web applications at the moment, it 
>> really lets your imagination fly.
>
> Would you care to give a bit more colour on this?  Sounds very 
> interesting.  So you have an executable running on client 
> machine that they need to download and install (fine for a 
> corporate internal application, I guess)?  And then you serve 
> your application locally, or from a combination of server and 
> local url paths?

I can't share source but the idea is simple. You configure a DNS 
subdomain my.domain.com => 127.0.0.1, and test that address with 
javascript when a logins to the public website, if it doesn't 
work you show a message "plugin required". The user downloads the 
plugin and executes it, an elevation request is asked once for 
the exec to copy itself to program files and to register the 
service/daemon or open it (the only user interaction required!), 
and then the page is opened in a new browser window (borderless) 
or he can also refresh the page. The plugin's reverse proxy 
delivers the AngularJs app that uses Json models to populate the 
templates.

The important part is this: Any routes registered in the 
redistributable app will be prioritized over the reverse proxy 
(if the reverse proxy was registered after them). The reason this 
works is, vibe.d calls the routes by the order that they were 
registered, up until the HTTP header is written.

This simple but effective architecture is robust even for public 
applications. If you don't do any code signing, you might have an 
additional popup before you can open it but that's it. The packed 
executable can be as low as 2mb

You can also have a long polling task to check for file updates 
and let the executable replace itself / restart itself.

It's all around fun and games :)


More information about the Digitalmars-d mailing list