Composable Architecture vs API-Led Architecture: what’s the difference?
Working through an integration project, or through any technology project where you have more than one enterprise technology platform, you will likely need an API (application programming interface) solution. An API is simply a way for two or more programs or applications to communicate with each other. There are several different types of API that developers use to complete their projects. Each has their own advantages and disadvantages, and you should select one that best meets your unique needs.
At Apps Associates we work frequently with MuleSoft for our customers’ integration needs. Recently, MuleSoft announced changes to their pricing structure which may influence the type of API users select, particularly between API-Led Architecture and Composable Architecture.
If you use MuleSoft, this change could affect how you are charged for your licenses, and how you interact with MuleSoft data. Let’s review the difference between Composable Architecture and API-Led Architecture.
What is API-Led Connectivity
API-Led Connectivity is a methodical way to connect data to applications through reusable and purposeful APIs within an organization’s ecosystem.
API-Led connectivity is built upon organized, consumable, and discoverable APIs that fall into three categories:
- Experience API: built for delivering user experiences or when there is a need for a web API. These are often built for end systems which consume and modify the data of an application.
- Process API: built for reusable, composable business logic by segregating user experience and underlying systems.
- System API: built to access core systems and provide data by segregating the technology of the core systems. These APIs help users to easily consume the data without needing to learn underlying system technology.
How API-Led Connectivity Builds your Application Network
API-led connectivity models are based on building reuseable, discoverable APIs. Adopting this type of API strategy in your organization may help stakeholders and developers in the long run; your organization can take advantage of discoverable APIs to extend the functionality of an API for a requirement, or build APIs which are not yet available, eventually growing the application network within the organization.
Advantages of Using API-Led Connectivity
There are pros and cons to using an API-led connectivity strategy at your organization. We’ve highlighted some of the main advantages and disadvantages here.
| PROS | CONS |
| Enables Parallel implementation. | Can result in unnecessary APIs/code |
| Enabling Reutilization of existing APIs. | Dependency on APIs |
| Granular level of implementation | More APIs More Maintenance like Monitoring, Governing, Alerts |
| Simulating APIs with Mock APIs | Increase in Network overload, latency and through put |
| Security | Increase in Network overload, latency and through put |
| Different strategies need to be implemented to control performance | |
| Cost in terms of runtime engines, messaging and network topology. |
API-Led is not the only API framework that you can use in your development. After evaluating your needs, you may discover that Composable Architecture fits your needs better.
What is Composable Architecture?
Composable architecture is a design pattern that allows developers to create reusable components to build applications more quickly and easily.
There are many similarities between API-Led and Composable Architectures, and API-Led is in fact considered a subset of Composable Architecture. While Composable Architecture includes reusable APIs, the main intention is to create reusable components which may or may not be APIs.
For example, if your application is connecting to a SaaS-based application which already has APIs implemented, it’s not necessary to create an API Layer on top of this unless you have a specific requirement which is not included as part of the original API implementation.
Let’s review some pros and cons of using Composable Architecture
| PROS | CONS |
| Parallel implementation of reusable components. | Dependency on Saas APIs Implementations. |
| Reduces Complexity in overall Application Network. | Sticks only to that particular application requirements including functional and non-functional some times. |
| Minimal decrease in network overload, latency and through put compare to API-Led. | No discoverable APIs, should use some documentation standards to show case reusable components. |
| No extra APIs layers. | |
| Increases speed of code development. | |
| Low maintenance of application. | |
| Reduces cost of servers and space. | |
| Not restricted to API based communication |
Should I Replace my API-led Connectivity?
If you have built your integrations using API-led connectivity, you may be wondering if you must update or edit the design. Fortunately, you do not have to update immediately.
Composable connectivity, however, does offer more flexibility – whereas with API-led you are required to use three levels of APIs (experience, process, and system), with Composable you may only need to develop what is necessary for business function.
To determine which method is best, we recommend you:
- Analyze the infrastructure of each system involved.
- Identify the need for an API Layer (see next section).
- Design based on three categories: Synchronous, Asynchronous, and Scheduled.
- Try using existing APIs and build new APIs only based on requirements.
Metrics to decide before building each layer of API-Led
As mentioned above, API-led connectivity requires three layers of APIs to be built. To determine if you need to go this route, you should start by determining if you need each individual layer of API.
Below are the criteria for each layer of API. If your project requires every aspect of the criteria, then you will need to build that API layer. If you do not meet all four, you have options outside of these layers and can likely utilize a composable model.
Criteria for Building System API:
- The underlying system does not have any APIs or pre-built connectors.
- You are required to add an extra security model or a proxy layer to connect the systems.
- The system is not exposed to the public or the outside world.
- Requirement of protocol transformation ex: SOAP to Rest, RFC to Rest.
Criteria for Building Process API:
- There is business logic to be implemented before sending data to System APIs.
- There is a need to transform the data between System and Experience APIs.
Criteria for Building Experience API:
- An end user needs to interact with the application.
How can we convert existing API-Led to Composable?
As mentioned above, there is not an immediate need to change from API-led to Composable connectivity. However, once you complete an evaluation of your architecture and connectivity, you may decide to update to reduce costs. This process is very simple; existing API implementations can be converted to reusable blocks and the existing logic can be called by flow references rather than API calls.
To summarize, there are many options for building your application integration strategy with MuleSoft, utilizing both APIs and flow processes. Apps Associates always recommends thoroughly evaluating your business objectives and needs before determining which method is right for you.
Looking for help with this process? The advisory team at Apps Associates can work with you to determine your overall business technology strategy, and our experts at integration can work with you through implementation and beyond. Contact the Apps team today.