Introduction
As MuleSoft Integration Specialists, we often hear the cry that ‘API Reuse is the key to success!’ However, if you’re new to MuleSoft, you may need help understanding what API Reuse is, what it signifies or why we even care. So, bearing this in mind, it would be good to look at the question more deeply. Not only that, I’ve also decided to illustrate it with a practical example rather than just explaining it in purely technical terms. So let’s delve into “MuleSoft and API-Led Connectivity: A Practical Example of API Reuse”.
Over the last few months, I’ve worked on a personal MuleSoft project exploring how to integrate with OpenAI’s APIs. I wanted to learn how to build AI-based applications using language models (such as ChatGPT) for processing power. We’re all aware that AI is a topic that’s all the rage, and Large Language Models (LLMs) are getting lots of exposure and attention. As an integration specialist, I also wanted to use MuleSoft as the integration layer between any frontend application I constructed and these backend services.
Now, API Reuse aims to reduce the effort required to build an Integration project, saving time (and money), something I wanted to do. It also aligns nicely with the DRY (Do Not Repeat Yourself) principle, which advocates building reusable functions and avoiding rebuilding the same functionality more than once, whenever possible.
API Reuse ultimately boils down to knowing your API estate, what functionality it encapsulates and being mindful of that when planning future developments. Gone are point-to-point integrations, replaced instead by small, targeted APIs. Note that the effort required to design for this reuse capability is made simpler when utilising MuleSoft’s API-Led Connectivity approach and implementing the Application network concept. Therefore, before we dive into my example, let’s have a quick refresher on some essential ideas poignant to this narrative.
API-Led Connectivity and the Application Network
I’ve written about these before, and many other articles already examine them both, so let’s only spend a little time revisiting those details.
API-led Connectivity is an approach to integration that uses APIs as small building blocks. These blocks connect applications, systems, and data in a modular manner. It utilises a three-tiered technique, with each API in these tiers having a limited and defined role.
An Application Network encloses a connected ecosystem of applications and services facilitated through communication between APIs. These APIs follow the design principles laid out by API-Led Connectivity and foster the principles of API Reuse.
My Practical Example
Although the Reuse principles are not specific to my example, I chose this project because it illustrates them well. So, before we delve deeper and give some context explanation, I’ll quickly summarise the overall objectives of my Proof of Concept (PoC).
- Connecting Amazon’s Alexa to ChatGPT.
- Building a personalised chatbot and integrating that with ChatGPT.
- Creating a Q&A tool that uses ChatGPT to answer user queries over a given document.
Fortunately, this splits nicely into three phases. The high-level Application Network diagram below illustrates this better and shows where I have anticipated API Reuse.
To learn more about what was developed for each phase, please read the following blogs: Phase 1 & 2, Phase 3. Though, as I said, they are not explicitly related to the concepts in this article and are not a prerequisite, feel free to read them if you are curious to understand what I’ve learned.
As you can see from the diagram, I reused APIs built in earlier phases as I began work on each new stage of development. Instead of rebuilding connections, existing APIs were reused, leading to me achieving my goals faster. Imagine if I’d rebuilt the APIs every time or (even worse) used brittle, point-to-point connections. Not only would there have been no reuse, but the ability to swap out underlying services for new ones would have been time-consuming (such as changing the LLM from OpenAI’s ChatGPT to Google’s Bard). If this was a commercial project, the cost might have been prohibitively high and likely very time-consuming; I’m sure it would never be done.
Look at the diagram below for another perspective of how each subsequent stage was developed on top of each preceding phase. By the end, although only four new APIs were built in that final phase, the complete solution had twelve APIs.
Conclusion
This blog, “MuleSoft and API-Led Connectivity: A Practical Example of API Reuse”, aimed to quickly demonstrate a practical example of API Reuse, illustrating the reduction in effort required to reach the final state. This was accomplished by designing projects following MuleSoft’s approach of API-Led Connectivity.
As I stated earlier, the subject matter of the project here is inconsequential to the overall principle of reuse. In fact, all projects will benefit from applying these principles to a lesser or greater extent. So, the conclusion is that it is always important to look for the possibilities of API Reuse.
When building any project, always use this principle when designing. Remember, the ultimate aim is to maximise resource savings and reduce expenditure.
Are you looking to get your MuleSoft or API project off the ground? Then don’t wait. Contact us today for a no-obligation chat with one of our experts.