Frontend Pattern — Atomic Business Components (ABC)

In this article, we are going to explore a pattern for frontend scalability. we are also going to explore the pros and cons of the ABC pattern.

Atomic Business Component

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

No EventBus or Communication between components

No Centralised Custom Data+Logic Store

In the ABC pattern, there is no such centralized stuff. each business component load/unload/work 100% independent of others. Think of every component as a mini-app itself.


We can immediately think of at least 2 atomic business components.

  • BranchCount component
  • TagCount component

In order to build and render these two-component, the only input is required is the repo name that is facebook/react

BranchCount component will responsible for fetching data, rendering and subscribing changes of data, and re-rendering.

When it is loaded on the DOM, it will fetch the necessary data. It shouldn’t depend on the parent to give the exact number of branches.

GraphQL is an excellent choice to fetch data. In GraphQL, one can easily fetch data in any structure and any level of granularity.

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

In fact, one should be able to load the above component using the following URL.

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 future, if somebody removes a component, all its metadata also goes removed.

Benefits of ABC pattern

  1. moveability: much easy to move any component from one place to another.
  2. lego-pattern: since components can be moved very easily, we can truly build applications like lego blocks.
  3. loose-coupling: components don’t depend on each other.
  4. removability: instead of using display:none, one can surely delete an old component without worry.
  5. replaceability: we can replace one component at a time without worrying about breaking the entire application.
  6. 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.

P1. Multiple components fetching the same data-points.

If two components require the same data points then one will be served from cached data. Components can bypass cache and request fresh data. In Apollo Client, components are not aware of the cache while making requests.

Take this example.

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

In the above code, the component doesn’t need to worry about that the data is coming from a cache or a fresh network call. The component is simply requesting the data-points and it is a headache of AC3 to figure out how to serve data(from cache or a new network call).

P2. Reactivity & Communication

Again, Apollo Client solves this problem for us. In Apollo Client, we can subscribe to queries using client.watchQuery. So whenever any data-point changes, other components will be automatically updated using Apollo Client.


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

Only conditions are

  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?

Q3 — is Redux fall under the ABC pattern?

on the Other hand, Apollo Client+GraphQL is excellent tech to build an ABC pattern web app.

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

ABC pattern clearly tells about not depends on any component and including parent itself.

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

in the previous example, the BranchCount component was fully working using the following url.

One can easily build a component loader that collects props from URL and load a given component with those props.

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

Downsides of this approach

  1. Enforcement in the entire team is difficult.


Because of Apollo Client and GraphQL, we can truly build web applications using Atomic Business Components (ABC) pattern.

There is no library or framework needed for the ABC pattern because it's an architecture pattern. One can use existing frameworks/libs like React/Angular/Vue etc. The team needs sufficient discipline to follow the pattern.

Let me know your thought on this.

If you like the article, please follow me at Twitter —

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