Building Highly Dynamic UIs using React and Sockets
About React — React is a powerful library for building user interfaces. One can think of it as a V (View) component in a typical MVC framework.
The aspect of React that makes it a great choice for building dynamic UIs, which are updated frequently, is Virtual DOM. You do not interact with the DOM directly and let React do all the interactions with the DOM. Instead, you interact with the Virtual DOM and React determines which DOM elements need to be updated and changes only those elements on each UI update. Therefore, if you have many independent components which are updated according to different time and state, then React will only update the component that which is changed without affecting other components. This makes it an ideal choice for event driven UIs, where each component’s data depends on events that are emitted at different times.
How we leveraged React and Sockets in building the user interface for Blockchain Service Framework
About Blockchain Service Framework:
The Blockchain Service Framework takes a configuration as an input. This configuration includes parameters like number of nodes and number of miners in a blockchain network, the blockchain platform, the cloud platform and the number of accounts and transactions to do between the accounts. Based on this configuration, it creates a blockchain network of nodes. These nodes are distributed among a number of virtual machines, which are created through this framework. In addition, when this network is created, it starts a number of transactions between these accounts.
There are different services which are part of the framework like Cloud Service, Blockchain Service,Experiment Service, etc. Cloud Service deals with the creation and destruction of VMs on cloud. Blockchain service deals with the installation and initialization of nodes and miners of the network. Running the experiment and generating transactions is the job of Experiment Service.
The framework emits different type of events related to the creation of virtual machines, creation of nodes, readiness of blockchain network and starting of the transactions. These events are emitted to a Pub-Sub Server (NSQ in our case).
Requirements for the UI
We have different server side components and services as part of the framework. These services interact with each other through REST APIs and by emitting events to the Pub-Sub server.
We want to see the real time updates of the framework. We would like to know when and what virtual machines and nodes are created, when does the virtual machine become ready and the network is created. This information is stored in the events, which are emitted in different point of time. Our UI consists of various components. One component shows the status and real-time information of each VM. Another component shows the information of each of the nodes in these VMs. There is a component for live event feed. We also have a component that shows a real-time graph of Number of Transactions vs Time.
These UI components change with events received from the Pub-Sub server. The UI needs to dynamically change in response to all of the received events . Also, the server should not melt down with polling of all the clients to check if any change occurred.
Why we chose React?
Since the emitted events are frequent and distributed in time, we do not want to re-render the whole UI on receiving an event. We would like to re- render only that component which is updated.
This is where the power of components, React and its Virtual DOM comes to our rescue. React only re-renders the component and DOM elements that are changed, leaving the unchanged components as it is. This makes our UI fast, fluid and responsive. Dividing our UI in many independent components keeps our code modular and easy to change. We only need to focus on the behavior of the concerned component without worrying about the behavior of other components in the page.
Basic Architecture:
In order to achieve this, we built a server, which listens to these events from the Pub-Sub server. We maintain a socket connection between this server and our UI. The server receives different events at different point of time. Through a socket connection, the server sends these events information to the UI. Now the UI updates the appropriate component based on the information that it receives from the server.
Challenges faced
One of the main challenges we faced in this event driven UI is that the events information and data structures are stored on the client side UI. Therefore, on doing a page refresh, all the stored information is lost. And, we cannot see the information of previous experiments. Similarly, if the socket connection between the UI and UI Server is lost, we cannot see the information of the events, which have occurred during that period.
To solve the above problems, we took an approach of storing the events information and creating the data structures on the UI Server. These different data structures store various information of the events. We created APIs, which are used by UI to get all the information related to the events and experiment. Now, on doing a page refresh, we are able to see the information of the experiment. So, this way we used a combination of sockets and APIs. Socket is used to push real-time information to the UI and APIs are used to fetch the information of experiment and events.
Currently, these data structures are stored in main memory, so they do not survive a server restart. But we can persist these data structures using a NO SQL database like MongoDB. More on this can be addressed in another blog post.
Testing Approach
Another challenge of building such an event driven UI is testing. If we want to test a new small change made in the UI, then we need to run the whole framework to get the required events. This is timing consuming and inefficient. Just to check a small change, so much computing power gets wasted every time. So to solve this problem, we built a framework simulator whose only job is to emit the required events at different time to the Pub-Sub server. We modeled this simulator as a FSM(Finite State Machine). This way we prevent the creation of VMs and nodes on the cloud and test our UI for small changes. It also provides freedom to the front end and back end teams to work independently and make changes to their code and not depend on each other for testing every small change.
Follow-up Blog Series
Based on the information above the following is what I am thinking of potential items for future blogs :
- Creating APIs to get the events information in case of lost socket connection and missed events
- Persisting the in memory data structures to keep the events information on a server restart
- Building a FSM Modeled Framework Simulator to ease testing
References
