Frontend Pattern — Atomic Business Components (ABC)

Atomic Business Component

Reusable UI components can be shared across apps and they don’t carry any business logic them. But business UI components have business logic and data. Business UI components are created on top of reusable UI components.

Almost every Web application is one big monolithic business component.

Atomic Business Component is a pattern where the smallest part of the entire web application is created in such a manner so that,

  • It doesn’t depend on the parent. It should work independently of the application or other components. In other words, It doesn’t depend on DOM or parent component hierarchy.
  • It should take minimum sufficient parameters and mostly from URL.

100% loose coupling

in the ABC pattern, the entire application is built using multiple smaller business components. and each component can be loaded/unloaded/work independently with each other.

No EventBus or Communication between components

in the ABC pattern, components don’t talk to each other. We will explore later that how to have synchronization between different parts of the app/component.

No Centralised Custom Data+Logic Store

Many UI application architectures make a custom centralized data+logic store which becomes a centralized piece and couple entire web application.


Take an example of the following screen from Github.

  • BranchCount component
  • TagCount component
// Correct way
<BranchCount repo="facebook/react"/>
// Wrong way
<BranchCount count="102" icon="branch"/>

In the ABC pattern, each component must be able to load via unique urls.

In fact, It is highly recommended to develop each such component in an isolated environment and once they are fully developed and tested, we should integrate them into the main application.


in the ABC pattern, all the metadata, like CSS styles, language translations JSON, etc are present with the component itself.

Benefits of ABC pattern

  1. scalability: highly scalable
  2. moveability: much easy to move any component from one place to another.
  3. lego-pattern: since components can be moved very easily, we can truly build applications like lego blocks.
  4. loose-coupling: components don’t depend on each other.
  5. removability: instead of using display:none, one can surely delete an old component without worry.
  6. replaceability: we can replace one component at a time without worrying about breaking the entire application.
  7. low-bandwidth: When designed with GraphQL, components only request minimum sufficient data.

Problems and Solution with ABC pattern

P0. Fetching data points at granular levels.

In the traditional REST world, creating API for each smallest portion will be problematic. GraphQL APIs come to the rescue. GraphQL APIs are not designed for particular UI components. We can query even the smallest data point using GraphQL APIs.

P1. Multiple components fetching the same data-points.

Two-component can query the same data point. It may result in multiple APIs call but Apollo Client 3 (AC3) provides an excellent mechanism to cache data from GraphQL APIs. Using AC3, we can solve this problem.

const { data } = await client.query({
query: gql`
query InitialGqlQuery($uid: String!) {
User(uid: $uid) {
projects {
variables: {
uid: userId
console.warn('Data Received', data);

P2. Reactivity & Communication

If one component updates some data-points then that change must reach the other parts of the application.


Q1 — Which framework or library (React/Angular/Vue) is best for ABC approach.

It doesn’t matter at all.

  1. You are able to load/unload your component with unique URLs in the app itself.
  2. Component fetches their data and don’t depend on their parents.
  3. Components don’t depend on DOM or parent hierarchy to work.
  4. Keep as small as you can.

Q2 — Difference Between Micro Frontend and ABC pattern?

AFAIK, The micro frontend architecture is about loading multiple apps/pages that are built using different UI libraries like React/Vue. We can still develop web-app using ABC patterns and use micro-frontend architecture to combine multiple web apps.

Q3 — is Redux fall under the ABC pattern?

No. as explained earlier too, Redux provided a centralized coupled architecture for the entire app. It's a custom data layer.

Q4- I am using React or a similar component library. Am I using the ABC pattern?

Without necessary discipline, One can write full spaghetti code using React where the entire application is fully coupled and a huge number of “props & data & functions” is passed again and again to the entire component hierarchy.

Q5- How to test that a given component is following the ABC pattern?

If one is not able to load a given business component using a unique URL then it is not following the ABC pattern.

Q6- Can we combine multiple ‘atomic business component’ to make a bigger ‘atomic business component’

Yes, We should.

Downsides of this approach

  1. IMO, AC3 and GraphQL work best. If your backend is not GraphQL then implementing this pattern is hard.
  2. Enforcement in the entire team is difficult.


Apollo Client and GraphQL solve the biggest problems in the frontend world about data layer management. It's like a unified and generic data layer. Otherwise, We need to implement custom logic and build our own data layer using redux or similar libraries.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Narendra Sisodiya

Narendra Sisodiya

12+yrs exp. JavaScript Expert. Full Stack Expert. React, Nodejs Mongo AWS, Terraform Pulumi. IITian, Open Source. Currently Software Architect @