This content originally appeared on Bits and Pieces - Medium and was authored by Mike Chen
Composable software is trending and how you should structure your web applications
Over the past decade, software development has undergone a massive transformation due to continuous innovations in tools, processors and novel architectures. In the past, most applications were monoliths and then shifted to microservices, and now we find ourselves embracing composability — a paradigm that prioritizes modular, reusable, and flexible software design.
Composability is more than a coding pattern — it’s a fundamental shift in how software is built, structured, and maintained.
Instead of writing separate, tightly coupled applications, developers now compose software using reusable business capabilities that can be plugged into multiple projects. This enables greater scalability, maintainability, and collaboration across teams and organizations.
At the heart of this movement is Bit Harmony, a framework designed to make composability a first-class citizen in modern web development.
Why Composability Matters in Modern Software Development
There are many conventional problems solved by composable software.
Beyond Strict Repository Structures
For years, teams have debated monorepos vs. polyrepos — both offering trade-offs in scalability, maintainability, and developer experience. Monorepos ensure consistency and straightforwardness for code reuse but become complex to scale, while polyrepos provide autonomy but introduce dependency management challenges.
Composability eliminates this debate by making the repository structure less coupled with how software is built. With frameworks like Harmony, developers can work with modular components that are independent of repository structure, enabling a truly decentralized development workflow.
Reusing Digital Assets Across Projects
In large enterprises, duplication is costly — not just in terms of code, but in wasted developer time and effort. Composability enables the reuse of business-critical functionalities across projects, ensuring efficiency and consistency.
Consider a design system — instead of reinventing UI components for every project, teams can maintain a single, shared repository of buttons, forms, and layouts that are easily consumed across multiple applications.
The same applies to backend services. A well-defined authentication module can power multiple products without teams having to rewrite login, authorization, and user management logic from scratch.
Composability ensures that foundational business capabilities — like authentication, payments, and content management — can be built once and reused everywhere.
Encouraging Collaboration with Inner Source
Traditionally, software is owned and maintained by a designated team, creating bottlenecks when other teams need updates or fixes. This centralized ownership model does not scale but has become the norm since cross-ownership makes it difficult to manage.
Composability embraces Inner Source — a practice that applies open-source development principles to proprietary software. Instead of relying on one team to maintain a piece of software, multiple teams can contribute, iterate, and improve shared components.
This collaborative approach fosters:
- Faster innovation, as teams build on each other’s work.
- Reduced duplication, since components are extended rather than rewritten.
- More robust and secure code, thanks to broader peer review.
Inner Source transforms proprietary software development into a more open, collaborative ecosystem — allowing teams to build better software together.
This approach becomes practical using components as the fundamental unit.
Going Beyond Components: A Need for Higher-Order Abstractions
We need more meaningful constructs and terminology to build scalable architectures. This makes it easy to communicate and organize components for efficient development and collaboration.
Scaling from Components to Structured Composability
When working with components, a common challenge arises: How do we structure them effectively?
Without a clear structure and terminology, composability can become chaotic — turning software into a collection of disconnected parts rather than a cohesive system.
A button, a form, or a sidebar are all components. But how do they come together to form something larger?
Learning from Atomic Design
A useful approach comes from Atomic Design, which categorizes UI components into five levels:
- Atoms — The smallest building blocks (buttons, inputs).
- Molecules — Groups of atoms (input fields with labels and buttons).
- Organisms — Larger UI sections (navigation bars, sidebars).
- Templates — Structural layouts that define content flow.
- Pages — Fully assembled views of an application.
By applying a hierarchical structure, Atomic Design ensures that components are organized, reusable, and scalable.
Learning from SOLID Principles
Beyond UI components, composability can extend to backend services, business logic, and infrastructure. This requires higher-order abstractions that are built with well-known best practices like SOLID. For example;
- Single Responsibility — Each component should serve one clear purpose.
- Open-Closed — Components should be extensible without modifying existing logic.
- Liskov Substitution — Components should be interchangeable without breaking functionality.
- Interface Segregation — Components should expose only necessary APIs.
- Dependency Inversion — Systems should rely on abstractions, not concrete implementations.
By structuring software this way, composability becomes a reliable, scalable architecture rather than just a pattern.
Challenges in Building a Composable Software Architecture
Though composability was around for decades, it became viable for general application development with the introduction of Bit, which addressed several fundamental challenges, including tooling, development, collaboration and sharing components.
Yet, there are several challenges we need to be aware of to make the best out of composable architectures.
Choosing the Right Structure
A common question when designing composable systems is:
Should we follow a layered, MVC, or event-driven architecture? Or something entirely new?
Traditional approaches — such as layered architectures (UI, business logic, data layers) or MVC architectures — provide a cohesive structure to organize code and divide responsibility. However, they are not inherently composable. However, using components can help to make these architectures composable.
Balancing Ownership and Maintainability
When multiple teams contribute to a composable system, ownership can become complex. Who maintains shared components? How are updates versioned and tested?
A well-defined ownership model — where components are grouped into scopes based on functionality — can help balance autonomy with maintainability.
Bit Harmony: Framework for Composability
Bit Harmony is a framework designed for composability, offering:
- Aspects — Modular units combining frontend and backend functionality.
- Runtimes — Components execute in either the browser or server.
- Slots — A dynamic extension mechanism for platform-wide integration.
- Dependency Injection (Inversion of Control) — Avoiding tight coupling through dynamic registrations.
Applications as Graphs, Not Layers
In Harmony, an application is structured as a graph of connected components rather than a traditional layered system.
For example, a Payments Aspect can be used across multiple applications — integrating seamlessly without requiring hardcoded dependencies.
With Harmony, applications are composed dynamically — designed bottom-up instead of dictated top-down.
Conclusion: The Future of Composable Web Architectures
Modern software is no longer just a collection of independent applications — it’s an ecosystem of composable capabilities.
With Bit Harmony, enterprises can:
✅ Build modular, reusable business functionalities.
✅ Enable cross-team collaboration with Inner Source principles.
✅ Design software as graphs, not rigid layers.
✅ Balance ownership, versioning, and maintainability through structured scopes.
Composable architectures empower teams to build faster, scale efficiently, and innovate with confidence. Harmony makes that vision a reality.
🚀 The future of software is composable. Are you ready to embrace it?
Learn More
- Introducing Harmony: Unified JavaScript Platform for Building Composable Frontends and Backends
- Composable Software Architectures are Trending: Here’s Why
- Why You Should Build Your Platform with Harmony
- OpenSource to InnerSource: Why Enterprises are Adopting this Strategy
Modern Web Architectures: Composability with Harmony was originally published in Bits and Pieces on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Bits and Pieces - Medium and was authored by Mike Chen
Mike Chen | Sciencx (2025-03-05T13:48:26+00:00) Modern Web Architectures: Composability with Harmony. Retrieved from https://www.scien.cx/2025/03/05/modern-web-architectures-composability-with-harmony/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.