Building a Scalable and Maintainable Front-End with Component-Based Architecture

In 2013, Facebook introduced ReactJs and changed the way developers built front-end applications. With its Component-Based Architecture (CBA), developers could divide the application features into smaller pieces and then encapsulate them to form autonomous and independent systems.

Over time, using Component-Based Architecture for designing and developing the front-end applications became best practice as development teams realized its benefits. How can you use it to build a scalable front-end? Before we get into that, here’s how Stefano Armenes explains scalability:-

Here are some factors of the CBA that can be leveraged while scaling a front-end –

• Reusability is one of the prime benefits of using a component structure. It helps maintain UI consistency and improves performance, code reliability, and security while scaling a front-end application.
• Better control over the code as components centralize the specific sections of code for developers to access them whenever they build common application elements.
• Easier deployments as individual components can be built, tested, and deployed without waiting for the entire application to be ready for production. Additionally, replacing existing features is possible without affecting the whole application.

Francisco Afonso discusses why a Component-Based Architecture plays a vital role in frontend development:-
But don’t take our word for it!

This article explores the examples of 4 top organizations – USA Today, PayPal, Walmart, and Flock, that have successfully scaled their front-ends with component-based architecture and development style.

Paypal built Component Explorer to share and explore components.

Paypal’s development teams had to solve the difficulty in discovering and sharing components. Component Explorer proved to be the perfect solution that hosted and displayed all components in one place. Further, they used component playground, Storybook to publish the components, and component bot to automate the workflow.
This is how Component Explorer and Storybook functioned––the process started with creating and documenting components with Storybook. After that, component cli and component bot automatically shared them in the Component Explorer.

Here are a few quick facts about Paypal’s Component Explorer:

• Interactive components allowed developers and designers to use them without installing them.
• All components were documented and were generated with Storybook docs. They were also packed with a user guide and rendering scenarios for non-technical users.
• Explorer-hosted version tracked components and allowed the users to access changes in the UI evolution.
• It also displayed the production apps that earlier used a component along with its usage and credits.
• Finally, the Storybook plugin system audited components to ensure efficient performance.

Similarly, development teams at Walmart had to find a robust solution to component discovery issues in the company.

Walmart leveraged Electrode Explore for their components

In 2016, Walmart.com catered to 18 million monthly visitors and 10,000 requests every second while adding over 1 million items to the existing 15 million. With hundreds of developers working on similar components used for various frontend applications, the chances of code duplication were high. While React’s component model made reusing the code much more straightforward, there were still many challenges on the way.

Walmart extended its services with 12 websites in 11 countries, including Sam’s Club, Asda, Walmart Canada, and Walmart Brazil. Naturally, its engineering teams were under tremendous pressure while trying to maintain UI uniformity. Furthermore, discovering and sharing 100+ components became a tough task for developers, project managers, and UX teams.

As a result, the developers at Walmart built a solution called the Electrode Explorer in 2016 to tackle these challenges. Intending to improve productivity and create new tools for future scalability, the company migrated to React/Node.js in less than a year.

Electrode Explorer was an independent web application that let the teams display, search, and modify all components. With this app’s creation, the developers had eliminated the need to install components locally and conduct time-consuming searches through multiple repositories. It enabled development teams to view each component with an auto-generated demo in a ‘component playground’.

Now that we saw the discovery and sharing of components, let’s take a look at how Flock built its own reusable components.

Flock built reusable components from scratch

It was a common practice for development teams at Flock to extract a repository component and use it in two or three different repositories. However, if there was a bug in a code, it also got copied in all the repositories. This resulted in developers spending too much time fixing the bug. Moreover, Flock allows developers to build an application for their Flock teams or even for the whole ecosystem, so maintaining a standard and consistent structure of components was the need of the hour.

The process of creating reusable components started with writing the components in Vue CLI. The developers built extensible components that can consume changes in the future. Although the developers had to restrict themselves from writing these components for situations that may not occur. 

Unit tests show developers if a core feature is compromised, so writing them was next in line. For this, Flock created a component library with reusable components. Divyam Rastogi recommends using Storybook to create standalone components and Lerna to modularize components into smaller and manageable repos when they get too heavy to manage.

On the other hand, here’s how USA Today adopted the Component-Driven-Development approach to creating a common ground for its design and development teams.

USA Today successfully implemented Component-driven Development (CDD)

With a host of developers, designers, and journalists in their employ, USA Today found itself struggling with the inconsistencies seeping into the system because of individual preferences. The massive scale of the organization with its countless participants made it difficult for them to:

• Maintain a consistent brand: The varied font styles, orientations, spacing, and other elements left the readers with an inconsistent user experience.
• Keep the TAT to a minimum: With no single source of truth in place, designers and developers often had to build modules from scratch using their intuition.
• Continue scaling with ease: Due to the lack of frontend strategy and guidelines, they couldn’t scale seamlessly and often faced roadblocks during design and development.

Thankfully, it didn’t take them long to notice they had no single source of truth, which happens to be the root cause of all these issues.

Soon, USA Today adopted the CDD philosophy and created a central design system that’d be the north star for designers and developers alike during frontend development and scaling. 

They also realized that the best way for the literature to provide answers for everything was to ask questions while building it for documentation. So while breaking it all down into modules and components, they want you to seek answers to these five questions when looking at a component:

1. What is it called?
2. What is it made of?
3. Which variants are needed?
4. How does it scale?
5. Which style variables are in use?

Well, what did they achieve with this exercise? 

USA Today’s design system turned out perfectly for their needs––i.e., to scale without affecting their brand integrity.

Scaling a front-end as your organization grows is similar to getting car insurance. You never know when you may need it but you should always prepare for such situations. Component-based architecture is a guaranteed way of ensuring that your system is not entangled in dependencies and bugs that severely affect your performance and ultimately, your business. Let us know if you have any questions, suggestions, or comments on front-end scalability and we’d be happy to talk to you!