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.
