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.

Reply via email to