www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Can vibe d leverage existing web technologies?

reply Intersteller <Galatic.Bacon Outerspace.com> writes:
vibe.d does not have much lateral support as the most commons web 
technologies do.  Can vibe.d leverage pre-existing techs such as 
php, ruby/rails, etc? Starting from scratch and having to build a 
robust and secure framework is really not the way to go.
Sep 13 2016
next sibling parent reply Brad Anderson <eco gnuk.net> writes:
On Tuesday, 13 September 2016 at 23:45:18 UTC, Intersteller wrote:

 vibe.d does not have much lateral support as the most commons 
 web technologies do.  Can vibe.d leverage pre-existing techs 
 such as php, ruby/rails, etc? Starting from scratch and having 
 to build a robust and secure framework is really not the way to 
 go.


Sure. Just use res.write(executeShell(["php", "-f", 
"somephpscript.php"]).output); or something like that.

But seriously, you probably don't want to do that. It's like 
asking if ruby on rails can leverage php. Sure, they can 
communicate over HTTP or whatever else they support but trying to 
execute PHP from within Rails or vice versa just isn't really all 
that beneficial.
Sep 13 2016
parent Intersteller <Galatic.Bacon Outerspace.com> writes:
On Wednesday, 14 September 2016 at 04:22:02 UTC, Brad Anderson 
wrote:

 On Tuesday, 13 September 2016 at 23:45:18 UTC, Intersteller 
 wrote:

 vibe.d does not have much lateral support as the most commons 
 web technologies do.  Can vibe.d leverage pre-existing techs 
 such as php, ruby/rails, etc? Starting from scratch and having 
 to build a robust and secure framework is really not the way 
 to go.


 Sure. Just use res.write(executeShell(["php", "-f", 
 "somephpscript.php"]).output); or something like that.

 But seriously, you probably don't want to do that. It's like 
 asking if ruby on rails can leverage php. Sure, they can 
 communicate over HTTP or whatever else they support but trying 
 to execute PHP from within Rails or vice versa just isn't 
 really all that beneficial.


It is if you want to use pre-existing technologies. There are 
tons of php frameworks for doing things. Virtually nothing exists 
for vibe.d. e.g., any e-commerce stuff for vibe.d? I turned up 
one outdated, unfinished, and unmaintained package for d. There 
are hundreds, if not thousands for php. So are you suggesting I 
do not use vibe.d?

It's not like ruby/rails because ruby/rails also has a larger set 
of technologies. You are comparing apples to oranges. vibe.d has 
nearly 0 while the others have nearly an infinite. If vibe.d had 
nearly an infinite I would be asking this question.

Hopefully your solution works. Thanks.
Sep 14 2016
prev sibling next sibling parent Kagamin <spam here.lot> writes:
http://code.dlang.org/packages/pyd - is python ok?
http://code.dlang.org/?sort=updated&category=library.scripting
Sep 15 2016
prev sibling parent reply Martin Tschierschke <mt smartdolphin.de> writes:
On Tuesday, 13 September 2016 at 23:45:18 UTC, Intersteller wrote:

 vibe.d does not have much lateral support as the most commons 
 web technologies do.  Can vibe.d leverage pre-existing techs 
 such as php, ruby/rails, etc? Starting from scratch and having 
 to build a robust and secure framework is really not the way to 
 go.


A good way to mix different technologies is to use a Apache or 
nginx proxy on the same server, so you can start using vibe.d for 
some parts and keep the rest at its place.

Regards mt.
Sep 15 2016
parent reply Intersteller <Galatic.Bacon Outerspace.com> writes:
On Thursday, 15 September 2016 at 14:31:28 UTC, Martin 
Tschierschke wrote:

 On Tuesday, 13 September 2016 at 23:45:18 UTC, Intersteller 
 wrote:

 vibe.d does not have much lateral support as the most commons 
 web technologies do.  Can vibe.d leverage pre-existing techs 
 such as php, ruby/rails, etc? Starting from scratch and having 
 to build a robust and secure framework is really not the way 
 to go.


 A good way to mix different technologies is to use a Apache or 
 nginx proxy on the same server, so you can start using vibe.d 
 for some parts and keep the rest at its place.

 Regards mt.


How is this done? How can it be done smoothly? I'm not sure how 
to partition the work load. While, say, some pages might be 
served from php, and others from vibe2, etc, it seems like it 
would be nightmare to maintain consistency and interactivity.
Sep 15 2016
next sibling parent reply Martin Tschierschke <mt smartdolphin.de> writes:
On Thursday, 15 September 2016 at 20:56:19 UTC, Intersteller 
wrote:

 On Thursday, 15 September 2016 at 14:31:28 UTC, Martin 
 Tschierschke wrote:

 On Tuesday, 13 September 2016 at 23:45:18 UTC, Intersteller 
 wrote:

 vibe.d does not have much lateral support as the most commons 
 web technologies do.  Can vibe.d leverage pre-existing techs 
 such as php, ruby/rails, etc? Starting from scratch and 
 having to build a robust and secure framework is really not 
 the way to go.


 A good way to mix different technologies is to use a Apache or 
 nginx proxy on the same server, so you can start using vibe.d 
 for some parts and keep the rest at its place.

 Regards mt.


 How is this done? How can it be done smoothly? I'm not sure how 
 to partition the work load. While, say, some pages might be 
 served from php, and others from vibe2, etc, it seems like it 
 would be nightmare to maintain consistency and interactivity.


First you need to run vibe.d and the .php part on the same data
(mysql for example).
Lets say you have a special feature -  like latest news, than you 
build the rendering of this with vibe.d and the rendering of the 
single news are still in php.
Than you may move this to vibe.d later and keep only your back 
end, for editing
the content in php. So the most read pages are served by vibe 
first.

The "only" problem is you have to build your layout twice,
in php and as diet template. :-(

An other option might be, to start with the admin back end, where 
layout is not so critical and add additional features like 
statistics or a special dashboard?

Regards mt.
Sep 16 2016
parent sarn <sarn theartofmachinery.com> writes:
On Friday, 16 September 2016 at 12:46:34 UTC, Martin Tschierschke 
wrote:

 The "only" problem is you have to build your layout twice,
 in php and as diet template. :-(


You also have to manage URLs across different codebases.  I'd 
recommend against splitting up a frontend like that because it 
adds a lot of extra overhead.  But creating a new backend server 
isn't so expensive (not free, but not so expensive).  For 
example, I once wrote a thin proxy server in node.js for a 
third-party service that only supported node.js.  It wasn't as 
nice as a native solution would have been, but, hey, it worked.

Of course, with PHP it doesn't have to be a server.  A script 
might be simpler.
Sep 16 2016
prev sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
On Thursday, 15 September 2016 at 20:56:19 UTC, Intersteller 
wrote:

 On Thursday, 15 September 2016 at 14:31:28 UTC, Martin 
 Tschierschke wrote:

 On Tuesday, 13 September 2016 at 23:45:18 UTC, Intersteller 
 wrote:

 vibe.d does not have much lateral support as the most commons 
 web technologies do.  Can vibe.d leverage pre-existing techs 
 such as php, ruby/rails, etc? Starting from scratch and 
 having to build a robust and secure framework is really not 
 the way to go.


 A good way to mix different technologies is to use a Apache or 
 nginx proxy on the same server, so you can start using vibe.d 
 for some parts and keep the rest at its place.

 Regards mt.


 How is this done? How can it be done smoothly? I'm not sure how 
 to partition the work load. While, say, some pages might be 
 served from php, and others from vibe2, etc, it seems like it 
 would be nightmare to maintain consistency and interactivity.


True. It is easier to maintain if you do a 'vertical split'. So 
each subsystem maintains a strict boundary. You have to be clear 
about the dependencies between subsystems and any data exchange 
should happen via an explicit api. So there is no shared database 
between the D part and the php part for example. Communication 
with json over http is common and well supported by vibe.d. See: 
http://martinfowler.com/articles/microservices.html

This a more coarse grained approach which reduces coupling 
between the different parts.

For example, you could write a small api with vibe.d which does 
image processing, or collects and manipulates data from third 
party apis, or whatever. The rails app handles authentication and 
ui, making use of the services that your vibe.d api provides.

Another example: if you have a reasonably standalone part of a 
webapplication such as administrative pages or whatever, you 
could program that in vibe.d and let an nginx server route 
everything /admin/* to that part. The rails app exposes an api to 
modify its data which the admin app build in vibe.d makes use of.
Sep 18 2016