Question : Micro services routing
Closed this issue · 2 comments
First of all, thx for your simple but useful POC !
We are refactoring a lot of apps in my company and we decided to go on the same architecture that you proposed ! We will use scala as a backend language.
I am not an expert in realtime communication and after analyzing your code, I have a question:
How do you manage the microservice routing ? How do you route you actions to the correct microservice ? I see an "address" property in message but you open only one websocket. Does it mean that you use a gateway that routes to the correct service ?
Right now, we do classic async requests for most of API HTTP calls, through dedicated ngrx effects. No realtime and routing required here, clients are calling directly the corresponding API/service.
On our app, we only have a dozen ngrx actions that are remote/realtime and distributed accross connected clients (mainly to know who is connected and what strategic actions they are doing, like replying to a comment).
So everything is going to be easily managed by a single Vertx instance / websocket connection.
We use eventbus addresses as "topics" that a client can subscribe to. Any "remote" Ngrx action publish to that topic will be distributed and received by all the subscribed clients, and executed as a "local" Ngrx action. Right now, not much is done server side in Vertx, it acts as a main broker to redistribute local actions and keep some data in cache with TTL.
In near future, we plan to implement webhooks to our Vertx app in order to be able to push remote actions created server side (for example by worker/job microservices).
I hope that it clarify our architecture and answer your question ;)
Yes thx, it's very clear ;)
In our side, we will try to use websockets for all remote actions with one socket per api/service. We aren't sure yet if we will do the routing on the angular side or with an api gateway. I would prefer the second implementation because it simplify the frontend which is only doing simple "REDUX" with one single websocket to manage. In my point of view, the frontend doesn't need to know what service are used behind...
But we keep also some REST calls, for oauth token request by example.
I'll close this ticket, thx again !