EDM – The UI

In this post, I’d like to talk about what I feel is a very interesting idea, I’d like to take the time to talk about engineering some user interface that interacts with an event driven microservice for a back end, whether this back end is utilising some message broker or something else is irrelevant. For argument sake, let’s just say that the back end behaves in some asynchronous manner due to the complex business logic and/or complex/time consuming processes that are involved.

For this example, I’ll use a delivery service as an example, to initiate an order it’s reasonable to assume that a customer has successfully purchased a product. In such a scenario, an event occurs, the purchase has succeeded, then this triggers a series of events to occur, an order is created. In the creation of this order, a few key pieces of information, such as the expected time of delivery & the date the purchase went through.

Let’s say that the order is now in a pending state, the purchase has been successful, the money has left the customers account, but the order hasn’t yet been processed by the warehouse. In such a scenario, you could quite easily have some backend system that communicates with some front-end application via SSE (Server Sent Events), WS (Web Sockets) or potentially some other HTTP mechanism that may implement some form of polling.

So, on the front end, the user would see something along the lines of “Your order is being processed, we expect that you should receive your product on xx/xx/xxxx @ xx:xx”, this is quite a common design for such a business process. Examples include Dominoes when you place a pizza order on their website, Amazon, etc, the idea is that it’s simple & the user will likely check the state of the order later. We could make this system more sophisticated & use notifications or send a text, email, etc, the idea is to ensure that the user is informed that the state of the order has changed for some reason or another. Whether the user decides to cancel the order, or the order has progressed to another stage in the order process, such as “Your order is being shipped”. In all these scenarios, some event has occurred, in such a scenario, the UI should be updated, as previously mentioned, whether you decide to use email, SSMS, notifications, etc is down to specification.

When it comes to implementing a UI to cater for asynchronous backends, depending on context of course, you don’t need to worry about informing the user instantly, if the interface reflects the current state of the process, that’s all that matters. You can even implement an interface that will update in real time, as the state updates, which in my opinion is the best that you can achieve. If the system is non-blocking, responsive, reactive, fault tolerant, quick/fast, etc, I’d say that you’ve done a pretty good job.

The best part about implementing such an interface is that users are natively familiar with it, regardless of how enterprise & complex the back-end architecture is, the UX is generally quite satisfying. You could go ahead & include some fun animations which is what has been achieved with the likes of Dominoes, in my opinion at least, this is a nice to have to say the very least, increasing the UX just that little more.