What is the Composable Architecture (TCA)?
Introduction
The composable architecture(TCA) is a design pattern that emphasises the separation of concerns and allows developers to create complex systems by composing smaller, simpler components. The idea is to break down a complex system into smaller, self-contained parts that can be easily combined and recombined to create a larger system. This makes it easier to understand, test, and maintain the code.
Why is Composable Architecture Important?
Composable architecture is important because it allows one to create systems that are flexible and scalable. When we build a system using composable architecture, we can easily change or replace one component without affecting the rest of the system. This makes it easier to maintain your code over time, and it also makes it easier to add new features to your system.
How Does Composable Architecture Work?
Composable architecture works by breaking down a complex system into smaller, self-contained components. Each component has a specific responsibility, and it communicates with other components through a well-defined interface. This makes it easy to change one component without affecting the rest of the system.
Here’s a simple example of how composable architecture works. Let’s say you’re building an app that allows users to view and edit their profile. You could break down the app into two components: a profile view component and a profile editor component. The profile view component is responsible for displaying the user’s profile information, and the profile editor component is responsible for allowing the user to edit their profile information.
These two components can be combined to create the complete app. The profile view component communicates with the profile editor component through a well-defined interface, and the two components work together to provide the complete user experience.
More Complex Examples
Now let’s look at a more complex example to see how composable architecture can be applied in real-world scenarios.
E-Commerce:
Consider a complex e-commerce system that includes a catalog of products, a shopping cart, and a payment system. Each of these components can be broken down into smaller, self-contained components. For example, the catalog component could be broken down into a product search component, a product list component, and a product detail component. The shopping cart component could be broken down into a cart list component and a cart checkout component. And the payment system component could be broken down into a payment gateway component and a payment confirmation component.
Each of these smaller components can be combined and recombined to create the complete e-commerce system. The product search component communicates with the product list component, the product detail component communicates with the shopping cart component, and the payment gateway component communicates with the payment confirmation component. In this way, the system can be built by composing smaller, simpler components into a larger, more complex system.
In the context of e-commerce, this architecture pattern is also called composable e-commerce. There is another term PBC used in context of e-commerce applications. PBC stands for Packaged Business Capabilities — for instance, shopping cart and checkout, promotions are some PBCs.
In the software architecture terminology, there is another related term used — MACH Architecture which stands for Microservices, API-First, Cloud-Native, and Headless. We can say MACH is a cloud based composable architecture. In terms of PBCs, one or more microservices can be used to create a PBC.
App Development:
TCA can be implemented on the app development side too. In general, there will be five main components
- State: A type that describes the data your feature needs to perform its logic and render its UI.
- Action: A type that represents all of the actions that can happen in your feature, such as user actions, notifications, event sources and more.
- Reducer: A function that describes how to evolve the current state of the app to the next state given an action.
- Store: A place that UI observes for changes and where actions are sent. Based on these actions, reducers are executed.
- Environment: A type wrapping all dependencies of app/feature.
TCA and state design pattern: The ideas behind TCA framework are very close to the state design pattern. The MVI pattern in Android for building UI is also based on state machine. MVI (Model-View-Intent) — is a UDF architecture from the MV* family.
Drawbacks, Potential Solutions and Best Practices
Composable architecture has some potential drawbacks, including:
1.Complexity: Composable architectures can be more complex to design and implement than monolithic architectures, which can lead to increased development time and cost.
To manage complexity, it’s important to have clear standards for communication and APIs between services, as well as good documentation and testing to ensure that services are working correctly together. Additionally, using microservices frameworks and tools can help to abstract away some of the complexity of building and deploying services.
2. Performance Overhead: Composable architectures can introduce performance overhead due to the need to communicate between services and coordinate their interactions.
To mitigate performance overhead, one can use techniques like caching and asynchronous communication between services to reduce the number of synchronous calls. Additionally, one can use load balancing and horizontal scaling to distribute traffic across multiple instances of a service.
3. Integration challenges: As services in a composable architecture are developed and maintained by different teams, integrating them can be challenging, especially if there are changes to the APIs or the way services interact with each other.
To manage integration challenges, it’s important to have clear API contracts and versioning policies, as well as good communication between teams. Additionally, using automated testing and deployment pipelines can help to catch integration issues early in the development process.
4. Operational complexity: Managing and monitoring a composable architecture can be more complex than a monolithic architecture, as there are more components to manage and monitor.
To manage operational complexity, one can use tools like container orchestration and service mesh to manage and monitor services at scale. Additionally, implementing logging and monitoring across all services can help to identify and troubleshoot issues more easily.
5. Debugging challenges: Debugging issues in a composable architecture can be more challenging, as issues may be spread across multiple services, and tracing the root cause can require deep understanding of the entire architecture.
To manage debugging challenges, it’s important to have good observability across all services, including tracing, logging, and monitoring. Additionally, using distributed tracing tools can help to identify the root cause of issues across multiple services
6. Security risks: Composable architectures can introduce security risks if services are not properly secured and authenticated, or if vulnerabilities in one service can affect the security of other services.
To mitigate security risks, it’s important to implement proper authentication and authorization mechanisms across all services. Additionally, implementing security testing and monitoring across all services can help to identify and address security vulnerabilities early on in the development process
Conclusion
Composable architecture is a powerful design pattern that makes it easier to build and maintain complex systems. By breaking down a system into smaller, self-contained components, you can create flexible and scalable systems that are easy to understand, test, and maintain. Whether you’re building a new app or working on an existing codebase, composable architecture can help you create better, more maintainable software.
Disclosure: This was an AI assisted article generated using Open.ai’s ChatGPT.
References & Further Reading/Viewing
- Sitecore — Composable Ecommerce
- Origins of Modern Commerce
- Collections from Point Free
- Pointfree TCA example (Source Code Examples)
- Kotlin example of TCA
- Jetpack Compose
- Jetpack Compose (Source Code Examples)
- Create a Component Based Architecture in Android
- Botomation — Declaratively composing bots
- Monolith to composable architecture — Magento
About the Author
Arpit is a seasoned technologist with vast experience in leading large cross-functional and cross-geography teams. Arpit is interested in early-stage investments in startups in sustainable fashion, clean energy, people tech(health & wellness, leisure, jobs & personal growth), web3, media tech/content creation, legal tech and ed-tech.
Arpit believes we should all contribute back to society. He has set his goals for social work in five broad areas. You can read more about the same in his blog post “Do Good, Together” on Tumblr. Arpit is interested in working with people who want to contribute towards the same goals.
You can follow Arpit on Linkedin and Twitter. If you are looking for any help or guidance or investment, please drop a mail to arpitg.smp18 [at] mdpalumni.iimcal.ac.in
