Think-Digitally.de

As a great fan of API-led integration technology, I want to highlight some ideas and approaches that need to be considered before starting with the design for a API network. Actually, I am working with MuleSoft and some of the technical terms refer to this integration platform. Please bear with me but I believe it is the best solution, but I am convinced that the basic idea of this article applies to other API-led integration solutions as well.

The one or the other may remember discussions from the “Platform Architect” course. We discussed in and out the benefits and pitfalls of the fine grained and coarse-grained approach. After some months working with MuleSoft my understanding of the differences and reasons for the one or the other is more transparent as it was before.

Do you believe that API design is important? I hope you do. If not, you may run into serious problems in later stages of your integration project. The simple difference between “fine-grained” and “coarse-grained” is – please allow me a first and simple approach to it – the number of APIs based on the same number of system integrations and non-functional requirements.

In other articles, the concept was introduced as the “right-grained” APIs. This implies, that there is “one” correct approach. I doubt, that this is the case. I also heard about “right-grained”. Even within one network, it could be beneficial to balance between these two and slightly change the approach depending on the requirements. Does it make sense to mix both approaches within one network? I think not. There are many reasons, which will be outlined in the next chapters. Besides, I have not seen a working network where the team used “vanilla” fine-grained and coarse-grained together and was successful in the end.

Let’s look at some formal aspects of the two approaches:

Maintainance

At first glance, coarse-grained APIs seem easier to maintain because there are not so many APIs. If you already have a relevant number of APIs and try to fight your way through the jungle, you may know what I am talking about.

Error handling

Are you using APIkit implementations? Then you may use error-handling on the level of the Router Flow. Let’s talk about a practical example. You have either only ONE SAP System API or you have created 10-30 based on the required entities or business processes. More APIs give you more flexibility in defining alerts or error flows. However, they may also lead to unexpected complexity through redundancy.

Communication

If you use the network for communication and reporting to other lines of business, then the fine-grained network brings more benefits.

The description of an API is clearer and leads towards the real business process, if there are more APIs instead of just one “Order Process API”.

Elegant development

I am not sure, whether elegant development is a KPI for your team – probably not. However, from an API developer perspective, a fine-grained approach makes the most sense, because it allows the developer to structure the flows and therefore the implementation of the API more effective and transparent. The flip-side of the coin is the possible duplication of code/components. In order to avoid this, some experience is required, not only from the developer but also from the CoE (if there is one) or the project management.

Licensing

You always need more CloudHub workers if you have more APIs, even when they are “smaller” from a functional perspective. This is a potential downside in terms license-costs. License costs are measured in vCores as you probably know. Each CloudHub worker need at least 0,1 vCore to be created.

Readability

I think it is fair to say, that smaller APIs can be easier understood and read. The more assets you have, the better you control the network from a functional perspective. Does that contradict my previous statements, that that as more API’s you have that this is harder to maintain? Not necessarily, it is just the flip side of the coin. The decision of the Mule architect is simply what counts more in the specific case. Either you want to have atomic functions which are easy to understand, or you like less API’s which are better to maintain from a technical perspective.

You have to make sure, that everybody understands the meaning and interactions between the APIs.

Performance

Performance could be the most important non-functional requirement for a project that implements an API network. The number of APIs influences the performance in several ways. The most obvious reason is latency. The more APIs, the more transformations and probably more HTTP requests in and out which creates a higher latency. If this is critical for you, this leads to fine-tuning API parameters and requires caching or intelligent ways to parallelize the integration flow.

Believe me or not, in the end, the reliability and acceptance of your integration network will depend more on other factors. However, the way towards this holy grail can be dramatically influenced by the decision how you design your API network.

API FOREVER!