Recently I heard two talks by Fred George a leading Agile evangelist and software consultant. The talks were about micro-service architecture and how to do it correctly. The talks are below. Lets dive in.
What Fred proposes in both of these talks is piping all interesting interactions into something he called an event bus. He uses this term to describe a messaging system that can be published into and subscribed on. For example: a user makes a purchase. The event that is produced is perhaps a “purchase” event with a specific payload, which contains the user information and info about the purchase. This message/event is published to the “server” which in this case would be the “event bus” cluster. Now comes the interesting part. When the server environment is deployed long before the user purchases, specific services will tell the event bus that they care about specific messages. For example the Payment service will say that “I care about ‘purchase’ events”, while the Analytics service would ask for a handle only on ‘view’ events. Now that we have purchase data coming through the pipe, we can have the payment service pick that up and execute the payment. For the purpose of this we don’t care how the message gets back to the user for confirmation and feedback. Whats even more fun is that perhaps you have a Payment Analytics service that keys off of purchase events, or perhaps once the original Payments service has completed the payment it emits a “purchaseComplete” event back into the event bus. The PaymentAnalytics service could be anything, anywhere, as long as it has the handle on the event bus it can get those events and start to log what type of user purchased what.
Does any of this sound familiar? It sounds like the Flux, React/Redux/Saga or Ngrx/Store/Saga patterns to me! On the frontend we create these small services that only care if specific events are happening, then we do something interesting with them. Then perhaps we pipe the conclusion back into the application flow so that a ui service can tell a ui element to show that interesting bit of data.
The draw of the micro-service architecture is in the speed or development and refactoring and the lack of coupling. You can instead of debugging some huge codebase, simply scrap a poor service for a new 100LOC service that does the job better.
Porting that to the frontend, none of our services are really that big because all the hard work should be done on the server, or in a web/service worker. That being said taking the event bus idea we can have our web/service workers publishing into the bus and our ui element publishing into the bus. And then both can be subscribing to what they care about. Here is a little diagram. (P.S. This is exactly the idea behind the Angular 2 event bus idea for service and web workers)
It really is just the same architecture as the Flux pattern which inspires the Redux and NgRx store libraries, but I thought it interesting that the backend and the frontend are going similar directions.
A drawback is that you HAVE to use this approach to use any libraries that use the approach. That may seem obvious, but it also brings about one less obvious problem. The actions names will need to be pretty specific, unique or prefixed by library. If you use a generic event name, and then use a library or another developer takes the same name you will obviously get problems. In that case I will typically prefix my action/event names by library or module name. For example instead of an event named “switch_tab” I would use “TABS_SWITCH” “TABS” being the module and switch being the thing I want to do or if my library was called “easy_tabs” then I could say “EASY_TABS_SWITCHTAB” or something.
Comments? Please let me know what you are thinking.<img src=“https://medium.com//stat?event=post.clientViewed&referrerSource=full_rss&postId=fc2170e227e9” width=“1” height=“1”>