As a high-level definition we discuss composable in combining multiple building blocks, each solving for a business requirement. Digging deeper on the technical implementation, it’s clear that these building blocks must follow specific rules to ensure they can be leveraged and combined effectively. Combining many small monoliths would be a huge task, but services that apply these principles become easy to work with, extend, and merge making them fit the definition of composable.
API-First
API (Application Programming Interface) is a set of rules and access patterns that allow different software applications to communicate. While it is possible for API to be added to a monolithic system, taking an API-First approach prioritizes the design and flexibility of these APIs. An API-First design guarantees that all functionality is exposed via API and that the API contract is well thought-out rather than being a consequence of how the data is stored or the expected UI. An API-First service can be used to build any type of user experience, where APIs added later are highly influenced by the existing user interface and adds restraints to how it can be leveraged. Taking a flexible API-First approach is necessary for seamless integration between the many services leveraged in a composable architecture.
The term “Headless” is related to APIs. Headless defines a system where the frontend (client-side) and backend (server-side) systems are decoupled, allowing for independent development and deployment of each. This separation allows for a higher degree of UI customization than standard theming solutions.
Be careful when selecting services, while all API-First services can be considered headless, not all headless software is API-First. Some headless offerings were tacked on to existing monolithic applications and do not give the same level of freedom when accessing the API.
Modular Components and Services
This principle requires that all the building blocks are discrete, interchangeable modules, each responsible for a specific functionality. Each building block should be consumable individually without reliance or dependencies on other services. A lack of tight coupling ensures the service can be used where necessary and replaced if another service better fits the requirements.
This may sound very similar to microservices. Microservices are a cloud architecture design where an application is deployed as a collection of small, focused containers, often within a Kubernetes environment.
The major difference is that microservices can be loosely coupled and are typically deployed together in the same environment to minimize latency for intra-service communication. Composable services must be fully decoupled, are often provided by different vendors as a SaaS, and focus on a business need or requirement.
While microservices are not required to be a composable service, choosing solutions built on microservices guarantee a high level of modularity and typically have a greater ability to scale.
Cloud Native
While any application can be hosted in the cloud, cloud-native applications fully exploit the unique services cloud computing provides, both in how they are hosted and with configurable integrations connecting to those services.
While a traditional cloud-hosted monolith may require a virtual server for each instance, a cloud-native SaaS will leverage scalable containerization designed with auto-scaling to serve all users. This creates scalability and cost-efficiency. This is extremely important for composable commerce, as a virtual server has limits on scale, must be managed directly, and represents a point of failure for days of increased volume (e.g. Black Friday). This level of maintenance would be cost-prohibitive when combining many different solutions. Instead composable solutions must be resilient and reliable guaranteeing they will handle any traffic without manual configuration or maintenance.
Composable solutions also take an event-driven approach to data movement and allow end-users to subscribe to these events. These events could be exposed via webhooks, but the best providers can also tie directly into cloud services and publish the events to a queue. Having access to the events allows for real-time integrations and negates the need for scheduled jobs or large batch files.
Subscribe - https://www.youtube.com/JamesLuterek
Top comments (0)