In this post we will discuss about the approach to building the frontend of the websites in terms of the microservices paradigm, dataflow and communication between services through the exchange of events (messages). I will use Backbone.js framework as an example.
Why Backbone? Because it is out-of-the-box best (as far as I know) of JavaScript frameworks originally designed to work with the data – instead other frameworks designed to work with visualization layer at the first. If you agree that the models, relationships and business logic – are the core, then you should agree with me. There are other points of view, and other tools – more focused on html, visual effects and the interaction with the user.
This approach is reflected even in the set of Backbone tools: a lot of tools for data and extremely simple templater. Fortunately, you can use the Backbone along with any other templater engine.
The main components of the Backbone are:
1. Model.
2. Collection (of the models).
3. Controller.
4. Template.
5. Router.
There is a terminological difference: although Backbone refers to the concept of MVC, but the controller is called View here, and the representation – called a Template. Do not ask me why. This just need to get used to – and luckily, this is the only one drawback.
Backbone lifecycle:
1. A change in the model or collection occurs.
2. The controller receives notification about it.
3. View updates itself.
This is a “reactive principle”, which you often hear in conversations about React. Here it is the same, and more: if you have raw data in React, with Backbone you have strictly defined models, like in the backend application. Communication between components is built in the Backbone, and for the developer it looks like a typical publish-subscribe to the events. There is another broadcast system that implements pattern “Enterprise Service Bus” – called Backbone Radio (Wreqr), which essentially is a common bus messaging inside and outside the Backbone.
Conversely it works the same way: when the user has changed something in the web interface (for example, entered the text in the input field), the controller responds to it as an event, and makes changes to the model. You can automate this process (known as two-ways data binding), or you can done it manually in case if you have non-standard logic.
Example: there is a page with a table of users sorted by their rank, and displayed with score value. If you change the score for a certain user (exactly change the value in the model), it will redraws only his row in the table. If you change the order of users (make changes in the collection), the table will be redrawn entirely.
And think, what if:
1. Each model instance is a service.
2. Each collection is a service.
3. Controllers are a services.
4. Templates are a services.
When you change the model, it publishes its new state within Backbone (according to the Dataflow ideology). This message (this event) can be heared by collection and by controller too. Typically, in this case, the controller hears it and republish an event (with model representation as is) to template where it will be redrawn.
It’s very similar to service-oriented architecture based on events/messages processing, isn’t it?
For example, a typical task of filtering the collection (finding models which are matched to conditions) is performed like that: you can add boolean flag – let’s call it “visible” – as property of the model, and the “filter function” will iterate through the collection checking each model. If some model is matched to conditions – it is marked as “{visible: true}”, otherwise – false. If the new value is not different from the previous one, then nothing happens (row in the table remains as it is – as visible or not visible). But if the value has changed – the raw will be redrawn (shown or hidden) by event-driven approach.
This is a very cost-effective way, and you probably often heard about it in React, where same algorithm is even presented as a know-how. Notice that you aren’t need to do something else (create a custom controllers, actions and so on). All that you are need is to change the models state.
However, there are more interesting things: the interaction with the backend. When the model changes its state, it can cause a persisting its new state to the backend. Technically – by sending a HTTP-request, but we can say what is going on by publishing/sending the event – with the new state of the model, according to the Dataflow ideology.
On the other hand, if you build the backend on the same principles, the backend updates of the model’s state are also published as an event/message, and also sended to the frontend (through SSE or WebSocket transports). I recently published working example how it works.
Message is received on the client side, and published into common service bus (based on Backbone Radio in this context). Further it may be catched, for example, inside the collection – and be merge into itself, with updating the state of a particular model in Backbone. Well, then you know: update of the model will cause redraw of the template.
This is an excellent opportunity to build “social” and interactive web sites: a list of comments under the post, the likes counter (with names), lists of answers to questions – all of these are updated in “real time” through the fundamental mechanisms, without any custom controllers or methods.
That’s all. You have built a system in which backend and frontend components operate within a service-oriented approach and communicating through messages.
