At Druva, we believe in creating a delightful user experience by not only providing good visual design, but also building a robust UI (User Interface) architecture and adhering to the best practices for front-end development. The commitment to building top-notch UI design and user experience is unfaltering. Let’s explore how the front-end architecture at Druva has not only helped create a fast and responsive UI, but also helped in adopting modern design principles.

As our offerings expanded over time with multiple product capabilities and we moved towards building a platform, the UX workflows started becoming richer and more complex. The earlier front-end architecture heavily utilized server-side rendering along with partial rendering capabilities. At the client end, we had a custom UI framework written in jQuery for calling the right server endpoints and dumping the response to the corresponding portion of the page, taking care of all common UI norms such as notifications, loaders, navigation, and DOM and BOM manipulation.

However, even with the advantage of quick server-side rendering, the heavy network usage and prolonged TTFB (time to first byte) and TTI (time to interact) soon became a hurdle in achieving a smooth user experience. The jQuery application code was struggling to achieve good performance at the cost of becoming more complex and unmaintainable. The zest to improve the performance of our web application is what led us to look into the world of client-side rendering.

Exploring client-side rendering with AngularJS

We began exploring the client-side rendering by evaluating popular client-side MVC frameworks of that era—AngularJS and Ember.js. We also experimented with using Vue.js along with jQuery on one of our products, Phoenix and went on to try out complex client-side templates with handlebar.js.

Using such client-side MVC frameworks and templating libraries helped us establish a few ideas to go forward with:

• Client-side rendering would be best suited for our product considering the complex information architecture (IA) spanning across pages.
• We could see a gain in the perceived performance upon separating sections of a page into independent areas such that the data is fetched independently.
• Consuming data from JSON-based HTTP endpoints would help us cleanly separate the UI layer with business logic.

AngularJS had a relatively larger community compared to Vue.js and Ember.js. Also, two-way data binding and debugging capabilities in AngularJS were better. We soon realized that using AngularJS was the way to go! It was helping us cross most of our hurdles and seemed promising and well suited for our enterprise application.

At that time, we didn’t want to implement a big bang change by migrating our entire application. Instead, we drove an experiment in a real production environment under heavy load, something we hadn’t attempted earlier. We grabbed this opportunity to revamp the inSync end user’s web portal and converted it to a more refinedAngularJS application, with enhanced UX revamp (as shown in Fig. 1) and major refactoring to enable JSON-based HTTP endpoints to support client-side rendering.

(a) Before

(b) After

Fig. 1: Visual refresh of the end user’s web portal

It worked! We could easily see a reduction in the rendering time of large data with client-side rendering. For example, on the Restore page, we could list thousands of files on the test environment of our new AngularJS application. We could also see an overall reduction in the web server load due to no server-side rendering. Also, as shown in Fig. 2, we were successful in achieving a perceived performance gain by providing the users something to interact with while the other parts of the page are still loading.

(a) t ~ 1000ms

(b) t ~ 2000ms

(c) t ~ 2500ms

(d) t ~ 4000ms

Fig. 2: In the AngularJS implementation, the different sections of a page gets loaded in stages, giving users something to interact with

However, there were a few hurdles along this path. Although using AngularJS helped us separate the responsibilities of API and UI, it still lacked a clean way to separate the involvement of business logic from UI. While bringing all the pieces of our web app together, we ended up creating a complex AngularJS codebase. Developers would need to take extra care to not let the “view” layer of AngularJS degrade the overall performance. inSync holds huge data of enterprise consumers and showing such huge dataset as a list is a challenge. Any user could have a huge number of folders inside a folder. We noticed this in our performance tests. The two-way data binding capability of AngularJS, which connected the “model” layer with the “view” layer made the browser rendering slow.

Componentizing the UI with React

Rendering large amounts of data efficiently was a need that we couldn’t afford to ignore. It was becoming difficult with the issues that we faced while upgrading AngularJS v1.6 to AngularJS v2.x. In came the answer to our problems – React. It was first used in one of our in-house hackathon projects and while being lightweight, it seemed promising to incorporate.

Around the same time, we wanted to revamp our inSync client app, which not only involved a UX revamp but also multiple enhancements too. We grabbed this opportunity to experiment with the React library in the inSync Client application. It was redesigned to use ElectronJS to build a cross-platform desktop app with JavaScript, HTML, and CSS (see Fig. 3). We also brought in WebSocket support and replaced the polling mechanism for real-time updates. In this, we grabbed an opportunity to move all business logic out of the UI layer. This was indeed a very successful experiment, which also reduced TTFB and TTI.

Fig. 3: The inSync Client app using React and ElectronJS

As Druva introduces new products and capabilities, we will be able to offer a consistent user experience across products, performant UI, and refined UX components built to meet the highest standards. Follow along for part two of the journey of Druva’s UI architecture experience in our next blog post.