Build and maintain cross-product Frontend Shared Packages

Context

Gorilla was my first development environment that made extensive use of Frontend Shared Packages.

The company’s products used many shared data-analysis and visualization capabilities. Rather than being reimplemented by each application, these capabilities were organized into packages that different products could compose.

They included map interaction, data analysis, and other shared frontend capabilities.

This was very different from my previous understanding of extracting a few common components.

The packages themselves were products that had to be designed, published, upgraded, and maintained over the long term.

My Decision & Action

I began building and maintaining Shared Packages and, for the first time, directly confronted the question:

What deserves to become a cross-product capability?

If application-specific business logic is put into a package, the shared layer quickly becomes bound to one product;

but if the package is abstracted too thinly, every product must redo substantial identical integration outside it.

When implementing capabilities such as data analysis and map interaction, I therefore paid closer attention to:

• How far a package’s responsibility should extend
• Which differences should enter through an API or configuration
• Which state should remain in the application
• How different products can use the same core capability without knowing one another’s business logic

These Shared Packages later became an important part of adopting the Nx Monorepo because dependencies between packages and consumers could finally be managed in the same workspace.

Outcome

Data analysis and shared frontend capabilities could be maintained consistently in packages, then composed by different products according to their needs.

More importantly, this was my first real exposure to:

designing frontend capabilities as platform building blocks.

Instead of rebuilding them inside an application for every product requirement.

Reflection

This experience had a major influence on my later work.

Previously, when discussing sharing, I tended to think of:

shared functions and shared components.

At Gorilla, I began to understand that a larger unit of sharing could be a complete capability:

with its own responsibility boundaries, API, version, and lifecycle, then consumed by different products.

This became an important foundation for the Shared Architecture, common LIFF layer, and monorepo work I later continued at Clinico.