I have an API for register users in "user service" after creating a user happen an event for send a welcome email. This requires the "user service" to call "the notification service". I have 3 layers in my project (Application - Domain - Infrastructure), in the user register API first application layer call domain layer and "create User Event" Occurs within the domain.
Should be the domain return the event to the application layer that sends to the application layer and application layer send this event to the infrastructure layer and infrastructure layer call notification service?
or should be the domain send the event directly to the infrastructure layer?
Which layer should be call the infrastructure layer for send data to the notification service?
I would make the Application layer in charge of calling Infra for notification, so your Domain don't have to bother about notifying what, when, how, etc.
And the less Domain has reponsabilities, the better, I think.
Related
In microservice architecture, It is suggested that:
client app to API gateway communication should be synchronous (like
REST over http).
API gateway to micro-service communication should also be
synchronous
But service to service communication should be asynchronous.
Another rule you should try to follow, as much as possible, is to use
only asynchronous messaging between the internal services, and to use
synchronous communication (such as HTTP) only from the client apps to
the front-end services (API Gateways plus the first level of
microservices).
https://learn.microsoft.com/en-us/dotnet/standard/microservices-architecture/architect-microservice-container-applications/asynchronous-message-based-communication
Now, If I understood it right, when user requests to API gateway, and in turn it calls the fist service, it will return a acknowledgement (with some GUID) which will be passed to client application. But services will keep on executing the request.
Now the question pop ups, how will they notify the client application when the request is processed completely. One way is that client can check the status using the GUID passed to it.
But can it be done with some push notification? How can we integrate server to server push notification?
I have little bit different understanding on this as it says communication between services should be asynchronous while communication to API gateway and API gateway to service should be rest API.
so we don't need to do anything as these are simple API calls and pipeline will handle request-response tracking while asynchronous calls between services will increase the throughput of the service.
Now, If I understood it right, when user requests to API gateway, and in turn it calls the fist service, it will return a acknowledgement (with some GUID) which will be passed to client application. But services will keep on executing the request.
No, the microservices should not continue to execute the request, it is already finished. They will, when it is required, update their internal cache (local representation to be more precise) of the needed remote data (data from the microservice that executed the request) when that remote data has changed. The best way to do that update is using integration events (i.e. when a microservice executes a request that mutates the data, it publishes an event to the subscribed microservices).
The microservices should not communicate not even asynchronously in order to fulfill a request from the gateway or clients. They should use background tasks to prepare the data ahead of time for when a request comes.
You're depicting a scenario where the whole interaction between the system and external actors (to be rude, the users) follows an asynchronous model. This is perfectly reasonable, but just if you really need it. Matter of fact, if you are choosing to let 'the outside' interact with your system through REST APIs, maybe you don't need it at all.
If the system receives requests through a synchronous application endpoint, such as REST endpoint, it has to complete requests before to send a response, otherwise it would be meaningless. consider an API like
POST users/:username/notifications
a notification is synchronous by it's nature, but the the request just states that 'a new notification should be appendend to the notifications collection of user'. The API responds 201 that means 'ok, the notification is already associated with the user, it will be pushed on some channel, eventually'. This is a 'transactional' way to describe an asynchronous interaction
Another scenario comes when the user wants to subscribe the notification channel. I expect that this would be implemented with a bi-directional, asynchronous, pubsub communication protocol, such as websockets.
In both cases, however, doesn't matter how microservices communicate with each other, if the request is synchronous, the first service of 'the chain' should wait until is ready to respond. This is the reason beacause API gateway forwards the request in http.
On the other hand, aynchronous communication could be used to enforce consistency between services, instead of to make the actual communication. Let's say that the Orders service sends data to a broker. each time some attribute on the orders[orderId] is changed, it published the change in /orders/:orderId topic. At the same time, expose an internal http point. each service caches data from the services which depends on. The user service make a GET /orders/:orderId , while sends a response to the requester, puts the data in a local cache and subscribes the orders/:orderId topic. each time that a 'mutation' is sent on this topic, the User service catches it and applies the mutation on the corresponding cached object. The communication is syncrhonous, keeps to be synchronous and it' relatively simple to manage; at the same time your system can hold replicated data and be still [eventually] consistent
I am able to successfully implement Server Sent Events, with Spring framework. I have a use case, in which my application [SSE-Publisher] will get notification from some third party application over the rest api.
And on receipt of these notification, it will be broadcasting events to the connected clients.
This works for single instance of SSE-Publisher and without load balancer.
If I have load balancer between SSE-Publisher and external application. Clients can subscribe to sse events on any instances of SSE-Publisher.
Now, when a notification is received from external application and it is routed to arbitary SSE-Publisher, the instance doesn't know how to publish the events.
So, in this case, can we store this SSEmitter object to some external store like MongoDB / Redis?
And later on, any SSE-Publisher can pull it from the backend and publish the event.
Firstly, here is state of my application:
I have a request coming in from a client (angularjs app) into my API (web api 2). This request is processed and a record is stored in a database. A response is then sent back to the client.
Currently, I have a windows service polling and processing this record(s).
Processing this record can be long running. As a side effect to processing this record, there might be notifications generated to be sent back to one or more clients.
My question is how do I architect this, such that I can utilise SignalR to be able to push the notifications back to the client.
My stumbling block:
I can register and store (in-memory backed by a db) the client's SignalR connectionid along with the application's own user identifier. This way I can match a generated notification with a signalr client.
At the moment, I'm hosting the SignalR hubs within the IIS process. So how do I get back from the Windows Service to IIS to notify the client when a notification is generated?
Furthermore, I should say I am already using SignalR elsewhere in the application and am using a SQL Server backplane.
The issue's with the current architecture:
Any processing is done in the same web request, and notifications are sent out via SignalR before a response to the client is returned. Luckily, the processing is minimal and very quick.
I think this is not very good in terms of performance or maintenance in the long run.
Potential solutions:
Remove SignalR hubs from IIS and host them somewhere else - windows service?
Expose an endpoint on the API to for the windows service to call to push the notification once a notification is generated?
Finally, to add more ingredients to the mix: Use a service bus to remove the polling component of the windows service, and move to a pub/sub architecture. Although this is more work than I want to chew off right now.
Any ideas/recommendations/constructive criticisms are welcome.
Thanks.
Take a look at this sample for starters
Another more advanced solution can be using a backplane to manage the communications between the front end and the backend...
HTH
Currently I'm building an application in a micro service architecture.
The first application is an API that does the user authentication, receive requests to initiate/keep a realtime connection with the user (via Socket.io or SockJS) and the system store the socket id into the User object.
The second application is a WORKER doing some stuff and sometime he has to send realtime data to the user.
The question is: How should the second application (the WORKER) send realtime data to the user?
Should the WORKER send a message to the API then the API forward this message to the user?
Or the WORKER can directly send the message to the user?
Thank you
In a perfect world example, the service that are responsible to send "publish" a real time push notifications should be separated from other services. Since the micro service is a set of narrowly related methods, and there is no relation between the authentication "user" service, and the realtime push notification service. And to a deep break down, the authentication actually is a separate service, this only FYI, There might be a reason you did this way.
How the service would communicate? There is actually many ways how to implement the internal communication between the services, MQ solution, which could add more technology to your stack, like Rabbit MQ, Beanstalk, Gearman, etc...
And also you can do the communication on top of HTTP protocal, but you need to consider that the HTTP call will add more cost.
The perfect solution is that each service will have to interfaces to execute on their behalf, HTTP interface and an MQ interface (console)
We are currently implementing a simple chat app that allows users to create conversations and exchange messages.
Our basic setup involves AngularJS on the front-end and SignalR hub on the back end. It works like this:
Client app opens a Websockets connection to our real-time service (based on SignalR) and subscribes to chat updates
User starts sending messages. For each new message, client app calls HTTP API to send it
The API stores the message in the database and notifies our real-time service that there is a new message
Real-time service pushes the message via Websockets to subscribed Clients
However, we noticed that opening up so many HTTP connections for each new message may not be a good idea, so we were wondering if Websockets should be used to both send and receive messages?
The new setup would look like this:
Client app opens a Websockets connection with real-time service
User starts sending messages. Client app pushes the messages to real-time service using Websockets
Real-time service picks up the message, notifies our persistence service it needs to be stored, then delivers the message to other subscribed Clients
Persistence service stores the message
Which of these options is more typical when setting up an efficient and performant chat system? Thanks!
You don't need a different http or Web API to persist message. Persist it in the hub method that is broadcasting the message. You can use async methods in the hub, create async tasks to save the message.
Using a different persistence API then calling signalr to broadcase isn't efficient, and why dublicate all the efforts?