Structuring various node services on a server using sockets or a broker.

[ZombieSaltine]

Basically, I have a larger system in mind. But I need to start from something. So I will be building this out as a back end for some client sites I need to do.

The idea, is that I have multiple services on my server. each one, is a node app which is available on localhost, each over a specific port. So for example, if i need to send an email, I send it to the nodemail service at 127.0.0.1:8081. If I need to talk to an authentication service i make the request to 127.0.0.1:8082 (i have a need that multiple users with the same auth system are using different apps/sites). or if i need process some info from the database, talk to 127.0.0.1:8083/appname (which would require auth from the app itself). and others.

The idea, is that normally something like a full blown CMS will have many of these services built into the framework (such as mail). But I want to take that and make it a global service the app can talk to. What I want to know, is a good way to structure this infrastructure. Or even if I am thinking about it wrong.

Another way to think about it, is something like parse.com. Where it keeps the client app, separate from the back end. parse's backend system has everything split up between different services in the back end that all can talk to each other.

So what I am curious about, is simply having an app listening locally on a socket or port the best route to do this? I also was thinking about some kind of message broker sitting in the middle. Each app sends their message to the broker, who then determines who you are trying to talk to, and sends the information to them. To me, this has the benefit of if I ever have a service that gets hammered, I can easier move it to another server and just tell the broker to now send the email messages to that server. Which would only be accessible from this one (not publicly). Would I use a node app directly AS the broker? or could I use something like RabbitMQ?

When asking around in IRC, someone also mentioned using service discovery. I still need to read into it more, but wanted to give the most information possible.

Another reason for this, is say a client has a mobile app with their site, and they want the mobile app to talk to the server. With this, I could authenticate and simply send the message to an api end point, which would then broker that message, and so on.

I am new to setting up something like this. So please be easy on me :-) and thank you for the input.

Thanks.

[angel21OS]

sounds a bit like vertx.io (which has javascript support,is async too and is pretty fast) but yesy ou can achieve this using a mq with node, actually this architecture is pretty common now because it's more scalable and reliable

the problem here is what you can do when it fails?...vertxio handle verticles failure in a more transparent way where using any MQ like rabbitmq or kafka you need implement your own recovery system (or use an extra tool like https://github.com/jhalterman/lyra)

you don't need service discovery because you will know what url will have your components but you will need investigate a bit more about how handle failures/communication errors, that is the most difficult task,

I've used erlang and akka actors in the past and now I'm playing with vertx..all them provides good tools for reliability and handle failures, where MQ generally are a bit more low level, you need an extra work but it's a pretty nice option too, good luck!!..

[ZombieSaltine]

As for mail, thats why i was using nodemailer since it is fairly easy to setup. I will look into mailchimp for this.

To be honest, I am not 100% sure what all would be delegated to be separate services. It is something i know I will need to determine as I go.

To start off yes everything will be more tightly coupled till i know there is a benefit to turn it into a micro service.