Need for Modular Architecture

# Need for Modular Architecture

### Motivation

The current offering of Catalyst's JavaScript SDK is done so in a modular structure. This structure is different from the conventional Monolithic SDK. The primary motivation that backed this offering was to ensure that you, as a developer, have precise access to the coding tools that you require in a more developer-friendly manner. Using Catalyst's modular JavaScript SDK, you will be able to use the same SDK to quickly code server-side and web-based applications.

### Why change from Conventional Structure?

Monolithic SDK cannot be leveraged to build your large scale applications in an optimized manner. While using the conventional Monolithic SDK method, even if you were going to use a singular Catalyst component, you were still required to install the entire SDK package. This produces the following disadvantages:

* Monolithic SDKs, are generally tightly coupled. If there was an update, to a component that you werent even using, you were still required to update your SDK packages, to ensure the code base remains functional.
* Installing the entire SDK, produces a lot of dead code, which makes your application needlessly clunky.
* Makes your code base harder to understand as the conventional Monolithic SDK is heavily nested in structure. This also produces the additional disadvantage of implementing unnecessarily long and verbose syntax.
* Overall, SDKs that are offered in the Namespace structure are just not optimized enough to handle larger enterprise applications.

All of these disadvantages can be effectively countered when you implement an SDK in the modular structure.

### Monolithic SDK vs Modular SDK

The following table clearly illustrates the benefits of migrating to an SDK with a modular structure by comparing it against the conventional structure.

<table class="content-table">
	<thead>
		<tr>
			<th class="w20p">Criteria</th>
            <th class="w25p">Monolithic SDK</th>
            <th class="w25p">Modular SDK</th>
            <th class="w30p">Resulting Advantage</th>
		</tr>
	</thead>
	<tbody>
		<tr>
			<td>Update & Patch Management</td>
            <td>You are required to update your entire SDK whenever there is a patch or enhancement in the SDK. This applies even when those fixes and enhancements are made to components that you have not used.</td>
            <td>You can isolate and install the required patches or enhancements only associated with the components that you are using.</td>
            <td>A modular structure never threatens the robustness or the functionality of your codebase, every time an enhancement or patch needs to be applied.</td>
        </tr>
        <tr>
            <td>Structure</td>
            <td>Hierarchical format, tightly coupled, and deeply nested.</td>
            <td>The SDK structure is broken into independent modules. the modules are not coupled with the others, and they are self-contained.</td>
            <td>This allows for easier imports. You only need to install the module that you require, not the entire package.</td>
        </tr>
        <tr>
            <td>Readability</td>
            <td>Complicated syntax and unnecessarily verbose.</td>
            <td>Precise imports and cleaner usage.</td>
            <td>Your codebase is easier to understand. This promotes smoother collaboration and even makes the learning curve more approachable for beginners.</td>
        </tr>
        <tr>
            <td>Refactoring Your Codebase</td>
            <td>Complex and at times impossible to remove or delete unused components from your codebase.</td>
            <td>Modular SDKs' loosely coupled structure makes it significantly safer and easier to refactor your codebase.</td>
            <td>Modular SDKs allow you to precisely access the required component. This ensures you can easily refactor your codebase. Additionally,  using the modular structure for your SDK allows for effective tree-shaking.</td>
        </tr>
        <tr>
            <td>Scalability</td>
            <td>Harder to scale using Monolithic SDKs.</td>
            <td>The modules are independent, so it can scale easily.</td>
            <td>Modular SDKs are better suited when you are coding enterprise applications.</td>
        </tr>
        <tr>
            <td>Tooling Support</td>
            <td>It is more compatible with conventional tools and as it is applied with older runtimes.</td>
            <td>Compatible with both older and newer runtimes.</td>
            <td>Modular SDK is the way forward, and it is designed to make it more compatible with existing and newer coding tools.</td>
        </tr>
        <tr>
            <td>Robust TypeScript Support</td>
            <td>Support is not full-fledged or it is severely limited in the current Monolithic SDK structure.</td>
            <td>You have complete TypeScript support in this SDK structure.</td>
            <td>Providing TypeScript support provides an easier and more compatible coding experience when using popular front-end frameworks.</td>
        </tr>
	</tbody>
</table>

Motivation

The current offering of Catalyst’s JavaScript SDK is done so in a modular structure. This structure is different from the conventional Monolithic SDK. The primary motivation that backed this offering was to ensure that you, as a developer, have precise access to the coding tools that you require in a more developer-friendly manner. Using Catalyst’s modular JavaScript SDK, you will be able to use the same SDK to quickly code server-side and web-based applications.

Why change from Conventional Structure?

Monolithic SDKs, are generally tightly coupled. If there was an update, to a component that you werent even using, you were still required to update your SDK packages, to ensure the code base remains functional.
Installing the entire SDK, produces a lot of dead code, which makes your application needlessly clunky.
Makes your code base harder to understand as the conventional Monolithic SDK is heavily nested in structure. This also produces the additional disadvantage of implementing unnecessarily long and verbose syntax.
Overall, SDKs that are offered in the Namespace structure are just not optimized enough to handle larger enterprise applications.

All of these disadvantages can be effectively countered when you implement an SDK in the modular structure.

Monolithic SDK vs Modular SDK

The following table clearly illustrates the benefits of migrating to an SDK with a modular structure by comparing it against the conventional structure.

Criteria	Monolithic SDK	Modular SDK	Resulting Advantage
Update & Patch Management	You are required to update your entire SDK whenever there is a patch or enhancement in the SDK. This applies even when those fixes and enhancements are made to components that you have not used.	You can isolate and install the required patches or enhancements only associated with the components that you are using.	A modular structure never threatens the robustness or the functionality of your codebase, every time an enhancement or patch needs to be applied.
Structure	Hierarchical format, tightly coupled, and deeply nested.	The SDK structure is broken into independent modules. the modules are not coupled with the others, and they are self-contained.	This allows for easier imports. You only need to install the module that you require, not the entire package.
Readability	Complicated syntax and unnecessarily verbose.	Precise imports and cleaner usage.	Your codebase is easier to understand. This promotes smoother collaboration and even makes the learning curve more approachable for beginners.
Refactoring Your Codebase	Complex and at times impossible to remove or delete unused components from your codebase.	Modular SDKs' loosely coupled structure makes it significantly safer and easier to refactor your codebase.	Modular SDKs allow you to precisely access the required component. This ensures you can easily refactor your codebase. Additionally, using the modular structure for your SDK allows for effective tree-shaking.
Scalability	Harder to scale using Monolithic SDKs.	The modules are independent, so it can scale easily.	Modular SDKs are better suited when you are coding enterprise applications.
Tooling Support	It is more compatible with conventional tools and as it is applied with older runtimes.	Compatible with both older and newer runtimes.	Modular SDK is the way forward, and it is designed to make it more compatible with existing and newer coding tools.
Robust TypeScript Support	Support is not full-fledged or it is severely limited in the current Monolithic SDK structure.	You have complete TypeScript support in this SDK structure.	Providing TypeScript support provides an easier and more compatible coding experience when using popular front-end frameworks.

Last Updated 2026-07-02 14:51:41 +0530 IST

Yes

Thank you for your feedback!

Send your feedback to us

Skip

Submit

NodeJS SDK Java SDK Python SDK Web SDK iOS SDK Android SDK Flutter SDK REST APIs Catalyst Functions

Modular JavaScript SDK

SDK Operations

Need for Modular Architecture

Motivation

Why change from Conventional Structure?

Monolithic SDK vs Modular SDK