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 :)
