Life-saving AWS EventBridge is worth everything
While building ShareBook, I was stumbling upon a long-running REST call I myself created :). I thought it was the most well defined/sequenced solution ever for sharing a book.
BUT, it took so much time that it totally broke the user experience of sharing a new book. This is what happened when a user shared a book:
- I take first the place where the book is available, then calculate the distances of this place from the other existing places
- then I gather all the users’ tokens where I need to send the notifications
- create the book in the database
- add the pictures of the book
- in case all is well after the previous steps, then a notification is sent to all the (eligible) users
- then respond OK — 200
Now after waiting for every step, all that took around 10 seconds to execute, and sometimes even the request timed out. It’s fast, isn’t it?
At first sight, I thought I could just change the AWS Lambda functions invocation by removing the await keyword I had before every REST calls. Sounds easy right!? But I realized all the calls were not performed because the calls didn’t even have the time to be fully transferred to the servers, and the main thread has already finished its job: too bad though it was really really really fast!
Then I googled a bit and found that there is a way to perform asynchronous calls by just adding a header X-Amz-Invocation-Type with a value Event to the calls. It’s already better the calls were not failing/timing out anymore, plus the execution time decreased a bit (just a little bit). But it was still long to make the user close the App and check her/his network.
After some good half-sleep, I was wondering if AWS has anything like RabbitMQ or Kafka or any other tools which can handle asynchronous tasks, and where I can just DELEGATE all the jobs I need to perform. It would be nice ;)!
So in the end, I found somewhere (guess where) that AWS has the so-called AWS EventBridge which is a serverless event bus to make event-driven applications simpler.
Hurray! After a few readings and some samples projects exploration, I decided to change the course of the App by using this technology: for sharing a new book, for sending notifications, for processing distances calculation. Everything seems so simple now. Of course, this is fully subjective!
Now, here is what happen when someone is sharing a book:
- from the place where the book is shared, I create an event that processes the calculation of the distances. It will be done in the background, no need to wait.
- in parallel, I gather the users’ tokens where to send the notifications
- then I create the book and add its pictures to the database: for those, I have no choice but to wait until it is successfully done
- and return directly OK
- just before returning OK though, for sending the notifications, I just create the event that is triggering the process which is taking care of sending them, still in the background. Those notifications are persisted before being sent in case the service is down while sending
Today the time to share a book is drastically reduced to around 1 to 3 seconds, depending on the fact there are pictures or not, and the user network. The event bus itself was not hard to set up and to be up and running. I will put up a small example with code for this. It’s probably clearer to see it in action.
