davrv93
2 sostenitori
How an Event-driven Architecture changed ...

How an Event-driven Architecture changed the way I design software

Oct 21, 2021

Read it on medium: https://medium.com/@davrv93/how-an-event-driven-architecture-changed-the-way-i-design-software-741f397d3055

Hi, this time I would share with you my experience using an Event-driven Architecture.

Definition

First of all, we have to understand What’s an Event-driven Architecture:

Is a pattern that uses events to trigger and communicate between decoupled services and is common in modern applications built with microservices

Reference: https://aws.amazon.com/es/event-driven-architecture/

Key components

  • Event producers

  • Event routers

  • Event consumers

Use cases

  • Email dispatcher

  • Payment processing

  • Fraud detection

  • Background tasks

  • Suscriptions

Characteristics

  • Flexible

  • Brings interoperability to software components

  • Language programming independent

  • Scalable

… and More!

Why did I chose an Event-driven Architecture?

The reason is very simple, I was developing a software that performed a synchronization task between several schemas and database engines, this did not prove to be something exceptional that a database Job or a command task scheduled under cronj obs could not solve. However, there was a feature that made this architecture pattern fit perfectly, giving total control to the user in terms of data management, although it is true that working with referential data with an established time gap allows streamlining the consumption of services (through temporary tables or periodic data loads), this leads to manually update data in case there is a critical need to view more current data, that is where the concept of event fit perfectly in my use case.

In my case study, the event would be a click to consolidate the data. When working under an event-driven architecture, the most important thing is to be able to identify the producer, routing under the router to the software components that will process the action known as consumers.

I understood that the best way to generate more value to my software solution was to provide full control and capacity of the module in its entirety, reducing manual tasks to the maximum.

Solution

The following diagram shows how I adapted the flow of my applications to conform to an event-driven architecture. In my case, I had an Angular client consuming REST APIs from a Laravel project on the backend. These APIs were running under a server and were proxied, so they were bound to meet certain conditions (timeout limits, cors, etc), so a task with a long response time would make my software development prone to fail.

I used RabbitMQ as a broker, I also took advantage of the websocket under STOMP that RabbitMQ provides, I must admit that working using the worker was of vital help, especially to provide certain features very well received by the end user, I was able to provide a loading indicator with percentages while each of the tasks were being performed.

My angular client used a library called ng2-stompjs to be able to connect, then I subscribed to the exchange associated to my queue created in RabbitMQ, finally I configured 2 consumers to process each of the requests generated by the producer (angular application).

In the following image we can visualize the connection configuration used in the ng2-stompjs library (https://github.com/stomp-js/ng2-stompjs)

Likewise, in the following image we can see an example of a subscription to the exchange configured in RabbitMQ.

Here I share a screenshot about exchange creation on RabbitMQ.

The next screenshot is a basic example of queue configuration on RabbitMQ.

Also we had to bind the queue by a routing key.

Finally, the consumers were configured using supervisord

So every time the user clics on sync button, the angular producer sends a message to the stomp socket, then RabbitMQ routes to the exchange, that’s the moment when the php consumers listens the event and completes the background task.

This is a screenshot of the websocket sending the event action, and also the heartbeat implemented by ng2-stompjs.

Conclusion

For me, the best solution I could have found is to implement an event-driven architecture, it not only allowed me to scale my solution, but also to give the end user the power to update all their reports with the latest information. Also, this solution has a lot of potential because through a message and consumers, it could be integrated to reduce many more steps of the scenario in question.

Comments

I would like to know your opinion! Feel free to write in the comments your appreciation. Thank you very much, God bless you!


Ti piace questo post?

Offri un libro a davrv93

Altro da davrv93