Engineering & Technology

Good Tools/Platforms List

Projects wise Assignee

Engineering Team

Roles & Responsibilities

Projects

Untitled page

Engg Internal Projects

Current Problems

Explore

Engg Publications

React Architecture for CEA's Client Portal

Executive Summary

The client portal will be a software-as-a-service (SAAS) initiated by the Clean Energy Associates (CEA) for a need to manage and communicate with our client intel effectively. It will be available for all the clients of CEA (people who purhcased CEA services) to interact with their reports, data and other service related progress. It will also be use as a key point to manage/track their relationship with the CEA and that can be:

View/download invoices

View/download agreements

View subscriptions

The client portal will also serve as a marketing tool which will create cross-selling opportunities for the existing clients

Purpose & Requirements

This document details the findings of the BiTS Team of CEA.

The technical proof of concept is the first phase in development of a new web-app for CEA. The primary objective of this phase is to figure out how to design our frontend architecture that provides the single go-to application for all the clients of CEA offered services.

The client portal needs to be developed by the internal BiTS team. As the key developers of this project, we are to design & develop a web-app in which we have multiple services that act as standalone applications. We need a solution that is scalable, reliable and easy-to-develop.

Potential Risk & Obstacles

Our current approach is that we are creating/adding all CEA services all in single repo and application. The issues with this approach are that:

Repo code will be bloated as we keep on adding new services

With changes in individual modules, there is a probability that some un-related part of our application might encounter bugs

If in future we decide to create a service that would be better suited to different javascript framework, it won't be possible for us to integrate

In a frontend monolith, teams working on separate services are still working on single codebase and which becomes increasigly complicated as our application increases in size. For example: Changes made in external components will have a direct impact on the internal services.

Possible Solutions

Monolith frontend Architecture: Monolith architecture are common architecture method followed by all developers/community all around the world. Due to its simplicity & easy development process, it is quite popular. Below are some of the key points:

All code/modules are written on the same codebase. Only external/3rd party libraries are used to extend the functionality.

Easier to maintain

Easier to debug

Easier to deploy & ship

Why we are not adopting it for the client portal:

As this is a good approach for the small project as there are limited features that needs to be shipped and also the limited team members work on the project.

Building services as NPM packages: NPM packages are a set of functionalities. It allows us to extend functionality of an application by dividing each module into different package. Below are some of the key points:

All code/modules are written on the different codebase as libraries.

Easier to maintain

Easier to debug

Easier to deploy & ship

Micro Frontends Architecture: Micro Frontends is an architecture to distribute code effectively with-in teams. It is to think as a composition of features which are owned by independent teams. Each team has a distinct area of business or mission it cares about and specializes in. A team is cross functional and develops its features end-to-end, from database to user interface.

Current Architecture: Monolith

The current architecture which we are using for all other projects has some strengths, omissions, and many problems which concern the execution of the client portal, and which have highlighted the need for a replacement system.

This section will discuss the problems, strengths, and opportunities for improvement of the current system. The issues discussed in this section are a combination of observations made during the project discussions meetings by the internal development team of BiTS.

The below are some of the observations in terms of drawbacks:

System usage/performance issues: From a user perspective, the primary problem with the current system involves load time and system availability. The application might takes minutes to load up.

Collaboration: From a developer perspective, the primary problem with the current system involves collaboration between multiple developers an head-ache. As the code will start to increase, it will cause more merge conflicts, and new on-boarded developers will takes months to understand the codebase fully.

Debugging/Maintainability: From managers perspective, the primary problem with the current system involves maintenance of code issue as it will cause time-frame to debug an exact issue/bug that might arise in the future.

The below are some of the observations in terms of strengths:

The single strength of the current system is in the area of fast development. Initial step of the project will be quick and deployment also not rely on any dev-ops or full stack developer.

Conclusion:

The current architecture which we are using is good for fast and quick development of the client portal but not suitable/reliable for future developments.

Solution Adopted: Micro-frontends

We have decided to go ahead with micro-frontend approach where our application get split into smaller vertical system.

Each CEA service will have its own frontend application and this will have lot of benefits including:

The risk of failure is isolated to a single service

The codebase becomes increasingly smaller making it easy for us to refactor

It becomes easy to understand for other members of the team as the scope of the application is much more narrow.

Each service will become independently deployable.

Debugging becomes easier as our app only shares state with components inside the application i.e.. micro-frontends

The below are some of the observations in terms of strengths:

Refactoring: In our industry we are constantly see evolving of new technologies. Especially in frontend development we see that frameworks are changing rapidly. With the micro-frontend approach, it becomes easy for us to refactor our application and adopt new/better framework depending on need of particular service. This also means that if a frontend framework becomes absolute we aren't stuck try to maintain application without any updates or improvements to that frontend framework that our application is running on.

Independence: The reason that building a react application where different members are working on a different service is not feasible is that there are a lot of things to consider before making changes to modules.

The reasoning behind this is the realization that communication between teams is expensive - really expensive. When you want to change a piece that others rely on and be it just a utility library, you have to inform everyone, wait for their feedback, and maybe discuss other options. The more people you are, the more cumbersome this gets.

The goal is to share as little as possible to enable faster feature development. Every shared piece of code or infrastructure has the potential for creating a non-trivial amount of management overhead. This approach is also called Shared Nothing Architecture. The Nothing sounds a little bit harsh, and in reality, it’s not that black and white. There are common parts like web fonts that are safe to share between teams.

Performance: The projects that are built on micro-frontend architecture are known to outperform monolith frontend architecture. This includes after responses, less code is shipped to the browser and overall decrease in total load times.

Iterative approach to updates: Since micro-frontend applications can break up large-scale workflow systems into smaller components that make it easier to create, update, and implement changing business processes. This can result in improved consumer experience as well as more effective business process management.

This means that organizations can more quickly and safely update and upgrade UX associated with their business unit’s rules or processes without external side effects. This allows for more iterative updates, decreasing the cost and complexity of experimentation.

Reusability: The projects that are built on micro-frontend architecture are a particular benefit for enterprises that build multiple applications that have some common workflow needs.

For example, if an enterprise has multiple sites that require a workflow for payment processing and the various automated business processes it triggers, they are able to use the same functionality across their applications, rather than building them from scratch every time.

Easier testing: The projects that are built on micro-frontend architecture are way easier to test as compared to a monolith frontend architecture. Since with micro frontends, you no longer need to keep track of the whole app. A team reviews a specific micro frontend, which has been changed or expanded.

Easier hiring of experts: With micro frontends, you look for professionals to work on a specific part of an app where a particular tech stack is used, so you do not need them to know technologies that other teams use.

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.