RESTFul API or Eventbus communication

[Eric Koston]

I want to build a microservices environment with vertx.

What makes me confuse is, in which way that the microservices should communicate with each other? Over eventbus or RESTFul API?

In my opinion, that communication over the eventbus makes it not as real microservices, because I have always to import the auto generated library that was created by vertx. What when I would create two independent project, so when I want to communicate with a service, so I have to import always the auto generated service proxy right?

Would be a RESTFul API not a better choice?

Thanks

[Tim Fox]

How long is a piece of string?

Vert.x is not opinionated and does not provide a "correct" way to do every thing. Vert.x is a toolkit and can be used in many different ways. For some people it may make more sense to use (mainly) HTTP/REST for communication and use Vert.x internally (this is what we do at my company for example). For others it might make sense to use the Vert.x event bus (e.g. if you know that all your services will be written using Vert.x)

(BTW you don't need to generate service proxies to create microservices on the Vert.x event bus, you can just use the event bus which comes with vertx-core)

[omid pourhadi]

Hi,

I've been also thinking about this lately. it would be great if someone clear it?

I guess working with event bus with generated proxy is more like a module than a service.

 

[Fuzz]

The pattern that Tim's outlined is better than REST/HTTP-everywhere.

We've taken the HTTP approach and have found some drawbacks. As a summary:

. More complex routing mechanics in the case of failure
. Generally more code to maintain
. Problems with transient state (as part of the HTTP invocations) and greater complexity for persistence of these
. Less flexibility and evolvability

In retrospect I wish our internal services were eventbus bound.

Regards
Fuzz

[Eric Koston]

What is your suggestion over HTTP/REST or EventBus. I know it depends on my requirements, but in general. 

Thanks 

[Jez P]

I don't think there can be a general recommendation without some notes on your requirements, specifically about how tightly coupled you want to be to vert.x for your microservices. There just isn't a general one-size fits all answer, so asking for an "in general" recommendation, especially immediately followed by "I know it depends on my requirements" is pretty problematic.

[ad...@cs.miami.edu]

Hi,

Along with what others have said, I would also ask yourself if 3rd parties wil need to access the API?  If so, they might not be too thrilled if you ask them to send something over the EB.  The design which has already been discussed is good:  use EB internally between vertx instances, and then you can easily expose an http api proxy for communicating with other orgs.  This is what makes sense to me.

-Adam