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.

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.

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.

http://code.dlang.org/packages/pyd - is python ok?
http://code.dlang.org/?sort=updated&category=library.scripting

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.

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.

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.

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.

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.