Spring Cloud: ZUUL + Eureka + NodeJS

Question

I am new to Spring-Boot(Cloud) and going to work on one new project.
Our project architect have designed this new application like this:

1. One front end Spring boot application(which is also microservice) with Angular-2.
2. One Eureka server, to which other microservices will connect.
3. ZUUL proxy server, which will connect to Front end and mircoservices.

Now, followings are the things I am confuse about and I can't ask him as he too senior to me:

1. Do I need to have separate ZUUL proxy server ? I mean, what is the pro and cons of using same front end application as ZUUL server?
2. How MicorService-1 will communicate with Node's MicroService-1? Some blogs suggesting the Sidecar. But again, why ? because I can directly invoke ReST api of NodeJS-1 from the Microservice-1.
3. (I know, this is very tough to guess but still asking) NodeJS services(which are not legacy services) are suppose to call some third party api or retrieve data from DB.
   Now, what I am not getting is why we need NodeJS code at all? Why can't we do the same in the microservices written in Java?

Can anyone who have worked with similar kind of scenario shed some light on my doubts?

Answer 1

I do not have the full context of the problem that you are trying to solve, therefore answers bellow are quite general, but still may be useful:

Do I need to have separate ZUUL proxy server? I mean, what is the pro and cons of using same front end application as ZUUL server?

Yes, you gonna need a separate API Gateway service, which may be Zuul (or other gateways, e.g tyk.io).

The main idea here is that you can have hundreds or even thousands of microservices (like Amazon, Netflix, etc.) and they can be scattered across different machines or data centres. It would be really silly to enforce your API consumers (in your case it's Angular 2) to memorise all the possible locations of each microservice. Better to have one API Gateway that knows about all the services under it, so your clients can call your gateway and have access to the underlying services through one single place. Also having one in your system will decouple your clients from your services, so it's possible to evolve them independently.

Another benefit is that you can have access control, logging, security, etc. in one single place. And, BTW, I think that you are missing one more thing in your architecture - it's Authorization Server. A common approach in building security for microservices is OAuth 2.0.

How MicorService-1 will communicate with Node's MicroService-1? Some blogs suggesting the Sidecar. But again, why? because I can directly invoke ReST API of NodeJS-1 from the Microservice-1.

I think you could use Sidecar, but I have never used it. I suppose that the question 'why' is related to the Discovery Service (Eureka in your architecture). You can't call microservice NodeJS-1 directly because there may be several instances of NodeJS-1, which one to call? Furthermore, you can't know whether service is down or alive at any given point in time. That's why we use Discovery Services like Eureka - they handle all of these. When any given service has started, it must register itself in Eureka. So if you have started several instances of NodeJS-1 they all will be registered in Eureka and whenever Microservice-1 wants to call NodeJS-1 service it asks Eureka for locations of live instances of NodeJS-1. The service then chooses which one to call.

(I know, this is very tough to guess but still asking) NodeJS services(which are not legacy services) are suppose to call some third party api or retrieve data from DB. Now, what I am not getting is why we need NodeJS code at all? Why can't we do the same in the microservices written in Java?

I can only assume that the NodeJS has been chosen because it has an outstanding performance for IO operations, including HTTP requests that may come in hand when calling 3-rd party services. I do not have any other rational explanations for this.

In general, microservices give you a possibility to have your microservices written in different languages and it's cool indeed since each language solves some problems better than the other. On the other hand, this decision should be made with caution and answer the question - "do we really need a new language in our stack to solve problem X?".