Has anyone got a small example of microservices using D, with Vibe.d or otherwise, that I can make use of? I need some examples of small microservices for a session at μCon 2015.

-- 
Russel.
=============================================================================
Dr Russel Winder     t:+44 20 7585 2200   voip:sip:
russel.winder@ekiga.net
41 Buckmaster Road   m:+44 7770 465 077   xmpp:russel@winder.org.uk
London SW11 1EN, UK  w: www.russel.org.uk skype:russel_winder

On Tuesday, 6 October 2015 at 16:12:12 UTC, Russel Winder wrote:
> Has anyone got a small example of microservices using D, with Vibe.d or otherwise, that I can make use of? I need some examples of small microservices for a session at μCon 2015.

As far as I know, there is no implementation of microservices as we see in the Java world. IMHO, D community should come up with a good microservices architecture. As you pointed out, it could be based on vibed.

On Tue, 2015-10-06 at 16:21 +0000, Dejan Lekic via Digitalmars-d wrote:
> On Tuesday, 6 October 2015 at 16:12:12 UTC, Russel Winder wrote:
> > Has anyone got a small example of microservices using D, with Vibe.d or otherwise, that I can make use of? I need some examples of small microservices for a session at μCon 2015.
> 
> As far as I know, there is no implementation of microservices as we see in the Java world. IMHO, D community should come up with a good microservices architecture. As you pointed out, it could be based on vibed.

Pity, microservices is a very fashionable thing just now, and Go is wiping the floor with Node and Java. Well that bit is opinion but… many people are getting into all this non-blocking, event-driven, shared memory stuff and boiling their brains, whereas the Go folk are doing blocking stuff using dataflow which is much easier to program.

-- 
Russel.
=============================================================================
Dr Russel Winder     t:+44 20 7585 2200   voip:sip:
russel.winder@ekiga.net
41 Buckmaster Road   m:+44 7770 465 077   xmpp:russel@winder.org.uk
London SW11 1EN, UK  w: www.russel.org.uk skype:russel_winder

On Tuesday, 6 October 2015 at 16:12:12 UTC, Russel Winder wrote:
> Has anyone got a small example of microservices using D, with Vibe.d or otherwise, that I can make use of? I need some examples of small microservices for a session at μCon 2015.

What do you mean by microservice examples? It is infrastructure methodology, not specific code thing, any simple network service can be viewed as microservice.

On 10/06/2015 01:54 PM, Russel Winder via Digitalmars-d wrote:
> On Tue, 2015-10-06 at 16:21 +0000, Dejan Lekic via Digitalmars-d wrote:
>> On Tuesday, 6 October 2015 at 16:12:12 UTC, Russel Winder wrote:
>>> Has anyone got a small example of microservices using D, with
>>> Vibe.d or otherwise, that I can make use of? I need some
>>> examples of small microservices for a session at μCon 2015.
>>
>> As far as I know, there is no implementation of microservices as
>> we see in the Java world. IMHO, D community should come up with a
>> good microservices architecture. As you pointed out, it could be
>> based on vibed.
>
> Pity, microservices is a very fashionable thing just now, and Go is wiping
> the floor with Node and Java. Well that bit is opinion but… many people are
> getting into all this non-blocking, event-driven, shared memory stuff and
> boiling their brains, whereas the Go folk are doing blocking stuff using
> dataflow which is much easier to program.
>

Felt stupid for not being hip to this "microservices" thing you say, so just looked it up. But it sounds to me like it's basically just a buzz-driven rediscovery of the basic principles of proper encapsulation and Unix philosophy ("do one thing and do it well").

(Kinda like how "cloud" sounds like a big fancy new revolution until you realize it's just the hip new word for "internet" or "hosted". Or "Facade design pattern" vs plain old "It's a thin wrapper".)

Does that sound about accurate, or am I missing something?

On Tuesday, 6 October 2015 at 19:07:32 UTC, Nick Sabalausky wrote:
> On 10/06/2015 01:54 PM, Russel Winder via Digitalmars-d wrote:
>> On Tue, 2015-10-06 at 16:21 +0000, Dejan Lekic via Digitalmars-d wrote:
>>> On Tuesday, 6 October 2015 at 16:12:12 UTC, Russel Winder wrote:
>>>> Has anyone got a small example of microservices using D, with
>>>> Vibe.d or otherwise, that I can make use of? I need some
>>>> examples of small microservices for a session at μCon 2015.
>>>
>>> As far as I know, there is no implementation of microservices as
>>> we see in the Java world. IMHO, D community should come up with a
>>> good microservices architecture. As you pointed out, it could be
>>> based on vibed.
>>
>> Pity, microservices is a very fashionable thing just now, and Go is wiping
>> the floor with Node and Java. Well that bit is opinion but… many people are
>> getting into all this non-blocking, event-driven, shared memory stuff and
>> boiling their brains, whereas the Go folk are doing blocking stuff using
>> dataflow which is much easier to program.
>>
>
> Felt stupid for not being hip to this "microservices" thing you say, so just looked it up. But it sounds to me like it's basically just a buzz-driven rediscovery of the basic principles of proper encapsulation and Unix philosophy ("do one thing and do it well").
>
> (Kinda like how "cloud" sounds like a big fancy new revolution until you realize it's just the hip new word for "internet" or "hosted". Or "Facade design pattern" vs plain old "It's a thin wrapper".)
>
> Does that sound about accurate, or am I missing something?

a half of it is the buzz and other half of is not. remember people talking about reactjs, go and rails being buzz? they were the same. we have built an online payment gateway and we are about to decouple our application and switch to microservices architecture. we have an api, a dashboard, a checkout page, mobile flow. we have to deal with accounting and reporting as well. and there is no way that this application will turn into a giant monolith. i don't want that. nobody wants that. it will become something we cannot handle.

another thing is whenever we do deployments we have to take down the whole application and go offline. i know there are other workarounds but when we only want to deploy mobile payments or the api, other functionalities should continue working and our customers should be able to pay.

nobody suggests starting with microservices architecture because you'll never know where things will lead you however when it becomes a giant the suggestion is to use microservices.

one other benefit of using this microservice is that you don't have to look for specific language programmers. you only need to hire good programmers as the only requirement  is to do one thing and and doing it well. the rest is about communication.

On Tuesday, 6 October 2015 at 16:12:12 UTC, Russel Winder wrote:
> Has anyone got a small example of microservices using D, with Vibe.d or otherwise, that I can make use of? I need some examples of small microservices for a session at μCon 2015.

on your email, in case it fits.  nanomsg and a little vibed

On Tuesday, 6 October 2015 at 19:31:20 UTC, Mengu wrote:
> a half of it is the buzz and other half of is not. remember people talking about reactjs, go and rails being buzz? they were the same. we have built an online payment gateway and we are about to decouple our application and switch to microservices architecture. we have an api, a dashboard, a checkout page, mobile flow. we have to deal with accounting and reporting as well. and there is no way that this application will turn into a giant monolith. i don't want that. nobody wants that. it will become something we cannot handle.

now a question for you.  do you wish you had built it from components from day one?  or do you see creating it as a blob to start with and then when the right divisions are clear factoring these out into micro-services as simply a natural part of the design process?  because you know much more by having started, and it's not so hard to refactor at this stage.

> another thing is whenever we do deployments we have to take down the whole application and go offline

pretend I'm asking you before it was deployed in production...

> nobody suggests starting with microservices architecture because you'll never know where things will lead you however when it becomes a giant the suggestion is to use microservices.

some people do.  but I would have thought the point I made above is the real reason.  it doesn't take very long to write it that way from the beginning IFF you know what you want it to look like before you start.  and maybe you don't.  but I am interested in what your experience has been.

On Tuesday, 6 October 2015 at 17:54:48 UTC, Russel Winder wrote:
> On Tue, 2015-10-06 at 16:21 +0000, Dejan Lekic via Digitalmars-d wrote:
>> On Tuesday, 6 October 2015 at 16:12:12 UTC, Russel Winder wrote:
>> > [...]
>> 
>> As far as I know, there is no implementation of microservices as we see in the Java world. IMHO, D community should come up with a good microservices architecture. As you pointed out, it could be based on vibed.
>
> Pity, microservices is a very fashionable thing just now, and Go is wiping the floor with Node and Java. Well that bit is opinion but… many people are getting into all this non-blocking, event-driven, shared memory stuff and boiling their brains, whereas the Go folk are doing blocking stuff using dataflow which is much easier to program.

I have never used Go, but isn't what you describe exactly what vibe.d is doing using Fibers ?

On Tuesday, 6 October 2015 at 23:01:43 UTC, Laeeth Isharc wrote:
> On Tuesday, 6 October 2015 at 19:31:20 UTC, Mengu wrote:
>> a half of it is the buzz and other half of is not. remember people talking about reactjs, go and rails being buzz? they were the same. we have built an online payment gateway and we are about to decouple our application and switch to microservices architecture. we have an api, a dashboard, a checkout page, mobile flow. we have to deal with accounting and reporting as well. and there is no way that this application will turn into a giant monolith. i don't want that. nobody wants that. it will become something we cannot handle.
>
> now a question for you.  do you wish you had built it from components from day one?  or do you see creating it as a blob to start with and then when the right divisions are clear factoring these out into micro-services as simply a natural part of the design process?  because you know much more by having started, and it's not so hard to refactor at this stage.

it's the latter for me. i am glad we have everything coupled together. this way we are able to see what parts can live by themselves and what parts cannot. and when you're building a start-up, i hardly believe designing microservices is the way to go. if you have time, if you have resources then go and design your microservices architecture. take your time, use your resources. but i didn't. i was one man and i did not have the time. now we are 4 people. we are not adding new features anymore and we know what kind of future is out there for our application. right now almost 95% of our application can be decoupled, do not depend on each other in terms of code. they can just communicate and get things done. also it means more uptime, more developers, more resources, etc.

we already have two microservices. one is for card vaulting and the other one is for end of day and cash report download/process service from the banks and other payment gateways. sometimes the industry you are in will push you that way.  and... one of the most important things for me with microservices is that now I can get Haskell and D in our codebase. :-)

>
>> another thing is whenever we do deployments we have to take down the whole application and go offline
>
> pretend I'm asking you before it was deployed in production...
>
>> nobody suggests starting with microservices architecture because you'll never know where things will lead you however when it becomes a giant the suggestion is to use microservices.
>
> some people do.  but I would have thought the point I made above is the real reason.  it doesn't take very long to write it that way from the beginning IFF you know what you want it to look like before you start.  and maybe you don't.  but I am interested in what your experience has been.

nobody, in their right minds, then. :)