I have this case where I have companies, and companies can have multiple users.
The sseemitter will only be sent on events that happen in the company, for example :
the company name changed event.
In that case, I would like to send a message via this event emitter to all open sessions of this company.
My question is do I need to create a sseemitter for each user, or should I just create a single emitter for the company and share it with all the users (of course after giving it to them via an endpoint).
Related
I am building a scalable chat application using Go and Redis w/ websockets.
I need to publish a new message using redis pub-sub model to other websocket servers to inform all the users (saved in memory of other servers) about the new joined user.
But the issue is, the publisher(also a redis client) receives the same message. Is there a direct way to solve this?
Workaround:
Check if the user for new user in the received event (for publisher) is in the list of current local users everytime.
WHY NEGATIVE VOTES? I'm so pissed at stack-overflow these days. People have no tolerance or too much arrogance
I have discovery service: https://github.com/Naresh-Chaurasia/API-MicroServices-Kafka/tree/master/Microservices-CQRS-SAGA-Kafka/DiscoveryService
I have Product Service: https://github.com/Naresh-Chaurasia/API-MicroServices-Kafka/tree/master/Microservices-CQRS-SAGA-Kafka/ProductsService
I have API gateway: https://github.com/Naresh-Chaurasia/API-MicroServices-Kafka/tree/master/Microservices-CQRS-SAGA-Kafka/ApiGateway
Product Service and API gateway are registered with discovery service. I use API Gateway to access the Product Service.
I am following a course to implement CQRS for products service.
Under ProductService, I have src/main/java/com/appsdeveloperblog/estore/ProductsService/command/ProductAggregate.java
Here the ProductAggregate is Command of CRQS.
It has the following methods (Please refer to GitHub for more details):
#CommandHandler
public ProductAggregate(CreateProductCommand createProductCommand) throws Exception {
...
}
#EventSourcingHandler
public void on(ProductCreatedEvent productCreatedEvent) {
...
}
It also has src/main/java/com/appsdeveloperblog/estore/ProductsService/query/ProductEventsHandler.java, which persist the product in H2 db.
I have also implemented src/main/java/com/appsdeveloperblog/estore/ProductsService/query/ProductsQueryHandler.java, which is used to query the db.
Here the ProductsQueryHandleris Query of CRQS.
My Question is as follows
What i am failing to understand that how and when is the Publish Event generated, and when the message is put in Messaging queue.
Also, is it possible that after the data is persisted to Event Store, it is not stored in Read DB. If yes, then how can we synchronize the Read DB.
What i am failing to understand that how and when is the Publish Event generated, and when the message is put in Messaging queue.
It happens after the events are published into the event store.
There are lots of possible designs that you might use to copy events from the event store to the event handler on the query side. These would include
Having the application code copy the event onto the message queue, which the event handler subscribes to
Having the event handler pull batches of events from the event store on a schedule
Having the event handler pull events from the event store, but using the message queue to announce that there are new messages to pull.
is it possible that after the data is persisted to Event Store, it is not stored in Read DB.
Yes. How common that is will depend on... well, really it mostly depends on how much you invest in reliability.
This is why the pull model tends to be popular - the read process can keep track of which events it has seen, and ask for the next batch of messages after X - where X is a time stamp, or a sequence number, or something.
Warning: if you are trying to roll your own event store, getting these details right can be tricky. Unless the details of the event store are part of your competitive advantage, you really want to buy reliability rather than trying to build it.
My first attempt to implement a microservice architecture using events with Kafka.
I have problems finding out how can I check for user credentials in a event.
My application is simple:
a service that controls users with email and passwords, able to create, edit and delete them.
a service that sends emails from those users.
My idea is to call create an event with a json like.
{
"status":"sendEmail",
"message":{
"sender":"abc#zxy.com",
"password":"123456",
"recipient":"jkl#asd.com",
"content":"this is my emails body"
}
}
Once I create this event at the second service, how can I validate with event that the user exist in the first service? I could easily do this wiht a REST communication but I would like to find out how to communicate responses between services with events messages.
Thanks.
You would need to either cache all user accounts in the second service (by consuming all user topic records), or perform an external lookup upon consuming email records. Messaging and RESTful services aren't necessarily exclusive.
FWIW, at least encrypt passwords before sending over unsecured/plaintext topics
Martin Fowler's description of the Event Collaboration pattern (https://martinfowler.com/eaaDev/EventCollaboration.html) appears to imply that requisite external data (data from other services) that is needed for a service to function should be replicated and maintained within the service.
This seems to imply that we should not resort issuing explicit queries.
For example:
Say you have a communications service that is responsible for sending emails to clients and is dependent order information (that lives in the order service) to send an order confirmation email.
With Event Collaboration, the communications service will have some internal representation of all orders that it will have built up by consuming relevant order creation/modification events.
In this example a query to retrieve order details will not be necessary to generate the confirmation email.
Are there any instances in which we would use explicit query messages rather than data replication when adopting the Event Collaboration pattern?
i think even in this case, what i would have done is create a consumer of OrderPlaced event in Order Microservice Only. That event processor will read all the details from order create a MailToBeSent event and write it on a Topic or Queue , which CommunicationService should listen and send the email.
Communication Service should not understand , how to create a email based on order(as core purpose of cummunication service is to send emails).
Design wise also communication service should not require to change every time you add a new service which want a mail sending functionality.
I am implementing an event-driven microservice architecture. Imagine the following scenario:
Chat service: Ability to see conversations and send messages. Conversations can have multiple participants.
Registration-login service: Deals with the registration of new users, and login.
User service: Getting/updating user profiles.
The registration-login service emits the following event with the newly created user object:
registration-new
login-success
logout-success
The chat service then listens on registration-new and stores some fields of user in its own redis cache. It also listens on login-success and stores the token, and on logout-success to delete the token.
The user service has the following event: user-updated. When this is fired, a listener in the chat service updates the data corresponding to the user id in redis. Like the chat service, the user service also listens on login-success and logout-success and does the same thing as what the chat service does.
My question is the following: is this a good way to do this? It feels a bit counterintuitive to be sharing data everywhere. I need some advice on this. Thank you!
Seems that there's no other way. Microservices architecture puts lots of stress in avoiding data sharing so as to not create dependencies. That means that each microservice will have some data duplicated. That also means that there must exist a way of getting data from other contexts. The preferred methods strive for eventual consistency, such as sending messages to event sourcing or AMQP systems and subscribing to them. You can also use synchronous methods (RPC calls, distributed transactions). That creates additional technologic dependencies, but if you cannot accept eventual consistency it could be the only way.