If you come from a Salesforce background, you might not be 100% familiar with the usefulness of an integration tool such as MuleSoft. Before we dive into MuleSoft, let’s first understand why we need an integration tool and what low-code or no-code technologies are.

Introducing no-code and low-code technologies

Programming and software development have been evolving over the years. At first, programmers needed to manually translate the behavior they wanted into computer code. You needed to study a programming language, practice it, and really polish it to be able to create unimaginable programs. Eventually, this transformed into human-readable words that you could input into the machine and it would automatically know what you meant.

Fast-forward to the year 2022 and you don’t even have to input words for the computer to know what you want to do. Computers are now good enough to work with icons, buttons, or drag-and-drop components. You don’t need to memorize commands; you just need an introduction to the tool and some practice to be proficient in it. What a blessing!

Of course, there might still be some need to write code in order to have more customized behavior that fits into more complex needs for the tool; but code in general, or a programming language, is easier to understand every time. 

Let’s now look into both no-code and low-code technologies in more detail.

No-code technologies

There are some applications that you can use that involve no coding whatsoever. A few examples that come to mind are Trello for project management, Canva for graphic design, or Zapier for integration/automation. You can use them without needing to know a programming language. It’s all done through clicks and configurations.

For example, Zapier and other tools such as If This Then That (IFTTT) are very popular because you only need your browser to access them. There’s no need to install an application on your computer or perform updates to your software. You can simply type the site name into your browser, create an account, and start using it right away. Of course, there is a learning curve to understanding how to use them. But this can be overcome in a matter of hours or days, not years of a professional career. With these kinds of integration tools, there are predefined apps that you can connect to through their Graphical User Interfaces (GUIs), such as Google Calendar, GitHub, and Philips Hue. You can create specific triggers to automate your day-to-day work. An example that comes to mind is sending a Slack message as soon as a commit is pushed in GitHub. You can just click through the flow to sign in to your accounts from these different services and you don’t even need to understand how their code works. That is the beauty of no-code technologies.

Low-code technologies

In low-code tools, you can still take advantage of drag and drop, clicks, and configurations, but there might be some coding involved for more precise functionality. However, programming is not the majority of the work. The technology does not revolve around the programming language; rather, it is considered a feature of the overall product. This is the case for Salesforce with Apex and MuleSoft with DataWeave. You can use Salesforce and MuleSoft without the need to use their programming languages, but they are available for you in case you need custom functionality.

We will look into these in more detail later in the book, but if you’re completely new to MuleSoft, picture this: you have a palette of connectors you can choose from. There is a Salesforce connector, a Workday connector, and a Slack connector, and they are ready for you to just drag and drop onto a canvas. Imagine these as building blocks that you take and start building something new. Alone they might not be super useful, but together they create utility applications. Well, you can take these connectors and build some logic. You’re building a backend application without the need to know how to code. The learning curve is smaller than trying to learn a programming language from scratch, because the visual assets help you to get a better understanding of what you’re building, instead of having to read actual code and understand what it does.

Let’s say that you have two variables: a and b. You want to compare whether b is greater than a and print b is greater than a, or a is greater than or equal to b otherwise. To do this in Python, it would look like this:

a = 1
b = 5
if b > a:
    print("b is greater than a")
else:
    print("a is greater than or equal to b")

Python is one of the languages that has a more human-readable syntax. Even if you don’t know Python, you’ll be able to read this code. However, you do have to get familiar with the syntax to know how to create this piece of code.

Now, let’s take a look at the same functionality, but using MuleSoft’s Anypoint Studio (MuleSoft’s Integrated Development Environment (IDE)). Remember that this is a visual flow where you can follow the components through icons, instead of just code. It would look something like this:

Figure 1.1 – Flow from Anypoint Studio

There is still some syntax involved. In Python, you wrote the condition as b > a, but in MuleSoft, our condition is vars.b > vars.a. So, MuleSoft is not completely free of code. But the majority of the components we used here did not involve writing code; they were connectors that can be configured in the canvas by drag-and-dropping.

Analyzing integrations

We can look at integration as some sort of translator that will allow system A and system B to talk with each other even if they both speak different languages. A quick analogy that comes to mind is if, for example, you speak English and need to speak with someone in Spanish; you can use a translator app on your phone to help you communicate with the other person. You don’t need to learn Spanish and the other person doesn’t need to learn English in order for you two to communicate effectively. This is achieved, thanks to your mobile device or the mobile application that you downloaded (the integrator).

Let’s now look into a technical example to demonstrate what integration does. If you’re not familiar with JavaScript Object Notation (JSON), it’s a type of data that is widely used nowadays because of its simplicity and easiness to read.

Let’s say that system A uses the following JSON object to describe a person. It contains the ID, FirstName, and LastName fields:

systemA-person.json

{
"ID": 1,
"FirstName": "Alexandra",
"LastName": "Martinez"
}

However, system B uses a different JSON structure to describe a person. Instead of the ID field, it uses id, instead of FirstName, it uses firstName, and instead of LastName, it uses lastName:

systemB-person.json

{
"id": 1,
"firstName": "Alexandra",
"lastName": "Martinez"
}

For a human, this might seem like a pretty straightforward transformation. The fields have the same names; they just have different upper- and lowercase letters. However, for a computer program, these fields are completely different. You need an integration that will help system A and system B to effectively communicate with each other even though their fields are different.

Of course, this example is simple compared to real use cases. This is just to give you a better idea of why you would need integration to connect different systems. In the real world, this data can be as short as what was just demonstrated or as long as 2,000 fields at a time.

Now imagine that we not only have to connect different data structures from system A to system B but also need to connect systems C, D, E, and F. All of them have their own data structures. Some of them don’t even use JSON; they use other data types, such as CSV or XML. It would be a lot of work to manually create code to be able to talk within all of these systems. Instead of creating a huge, tightly coupled, and hard-to-maintain application to connect them all, you can create small and easy-to-maintain Application Programming Interfaces (APIs) that will help you to integrate all of these systems and even leave space for any changes to the integrations that can be easily done. You’re not stuck with a ton of dependencies within the same project, but have different microservices to manage your whole application network, which brings us to our next topic.

The term integration is still an abstract concept without seeing some examples of technology that can implement it; but don’t worry, we’ll get there. Let’s now switch gears and dive into another popular term we hear a lot nowadays: API.

If you’re a visual person, we encourage you to watch this video, https://youtu.be/s7wmiS2mSXY, from MuleSoft to see an animation with a restaurant analogy that is widely used to explain APIs. This step is optional, but it might help you to understand this concept better. We will walk through the restaurant analogy in the following section.

Reviewing the restaurant analogy

When you go to a restaurant, after you sit down and get yourself comfortable, a server will come to ask for your order. You order your dish, the server writes it down, and then they proceed to communicate the order to the kitchen. The kitchen staff works their magic to cook your meal, and then let the server know when the meal is ready. The server picks up the dish and takes it to your table for you to enjoy.

Now, let’s break this down into smaller pieces:

1. You order your food.
2. The server writes down your order and sends it to the kitchen staff.
3. The kitchen staff prepares the order and gives it to the server.
4. The server picks up the order and brings it to you.
5. You receive your food.

We can look at this process as if it were API calls:

1. You call the Server API, requesting some food.
2. The Server API forwards your order to the Kitchen API, requesting your food.
3. The Kitchen API processes this information and responds with your food.
4. The Server API takes the food and responds to your order with the food.
5. You receive the food and confirm it is correct.

Figure 1.2 – API calls in restaurant analogy

The important things to understand from this analogy are as follows:

• You don’t know what the server wrote down in their notebook that was sent to the kitchen
• You don’t know all the ingredients that were put into your food or the exact process that the kitchen staff followed to prepare the order
• You don’t know what the kitchen staff told the server to let them know your order was ready

All that you know is that you ordered something and you received what you had ordered. APIs are a lot like that.

Fun fact

In a restaurant, you are the client and the person who brings your food is the server. Guess what it is called in the API world? In API lingo, the application that calls an API is called the client application, and the application or API that responds is called the server application.

Let’s now look into a real-life API to understand it better.

Exploring an API example

There are thousands of APIs that you can use in the real world. An example that we can use to demonstrate is the Twitter API. Twitter is a social network that is popular because of the maximum number of characters allowed in a single tweet. As of the time of writing, you can only post 280 characters at a time, which makes it ideal for short thoughts or quick updates about different topics. Once you have a Twitter profile and start following other accounts, you will be able to see the tweets from those accounts on your home page, or timeline.

If you go to the Twitter API documentation (developer.twitter.com/docs/twitter-api), you will be able to find all the different requests and responses that you can use to communicate with the API (the menu from the restaurant analogy, if you want to look at it that way).

Figure 1.3 – Twitter API documentation site

You can find the technical details to call the API and receive a list of your own tweets, for example; or you can post a new tweet using this API. This is useful if you want to communicate with Twitter using a backend application, if you’re developing your own app that can talk to Twitter, or if you want to integrate Twitter with other apps. For example, you can use social media tools (such as Hootsuite or Later) to schedule posts on your social networks. You give them the information you want to post and they take this information (or order) to the backend systems, which will make this possible (like the kitchen staff).

Any integration you create using the Twitter API can be written in any language or technology you decide. It doesn’t have to be compliant with how Twitter developed their APIs. That is the beautiful thing about the APIs. They offer their documentation so you know what’s available from them (like the menu from a restaurant) and you can make the appropriate requests to receive the data you need. The only thing you need to do is send the data in a format that the API is expecting, but any processing before or after the API request can be handled however you see fit.

To put it in more technical terms: you don’t know exactly what programming language the Twitter API is built in or what kind of data type it uses internally to process the information, but you do know the type of data it accepts and the type of data it returns. This is all you need to know to communicate with it.

Analyzing API components

Now that we have a better idea of what APIs are, let’s start looking into some components to define them. We won’t get into the technical details just yet, but it is good for you to start familiarizing yourself with this terminology.

Implementation

The implementation is the body of the API, that is, the code you choose to build the API with, the part that does the processing of the request and the response. We will use this term interchangeably with API throughout the book.

Request

Whatever is sent to the API is called a request. This includes different kinds of information that will tell the API what needs to be done with the data that is received. In the restaurant analogy, this can be, for example, a hamburger with no pickles, in a combo, with a large soda, and some fries on the side. 

Response

Whatever is received back from the API is called a response. This includes information to describe what happened in the processing of the requestor, for example, whether the request was successful or not or whether there was a problem with the request. In the restaurant analogy, this can either be the food you ordered (a successful response), the server telling you that the dish is no longer available but you can still order something else (a failed response with a workaround), or the server telling you that they’re closed for the day (a failed response with no workaround).

API specification

This specification serves as a rule, standard, or contract – however you want to look at it – to tell the client application (the application that calls the API or sends a request to the API) what kind of information it needs to send to the API in order to be accepted and processed as needed. For example, if the API specification says the API only accepts JSON requests and the client application sends an XML request instead, then an error will be returned stating that this data type is not accepted by the API. This is also a contract in the sense that it lists what the API may or will return to the client application, for example, a JSON object containing the id, firstName, and lastName fields.

Listing the benefits of using APIs

We still haven’t talked about the technical aspect of an API, but we’ve seen some examples and an analogy to help us get a better idea of this concept. Let’s list some of the benefits of using APIs:

• Loosely coupled: We touched on this subject briefly, back in our explanation of integration technologies. When you have a lot of systems that you need to integrate, you can create an application network with loosely coupled APIs that communicate with each other. This is a better alternative to having a huge, tightly coupled system that can’t let any more functionality in or out without having a dependency problem.
• Governance: With the APIs approach, you have a better chance of being able to govern your network. You can create API gateways, policies, and any sort of security to ensure that no unwanted intruder can get to your APIs. This can be a challenge with legacy systems sometimes because you need to create personalized code or external solutions may not be available for your system.
• Discoverability: APIs, as opposed to legacy systems, have a best practice of including documentation to use them. Since these are supposed to be open to the public, or easily discoverable, organizations also want their users (developers) to be able to find them and start using their APIs. Because of this, they try to generate better documentation with examples, use cases, descriptions, and even sample code.
• Easier maintenance: In hand with the loosely coupled and discoverability benefits, the developers that end up maintaining these APIs have a better understanding of their code. Because APIs are supposed to cover a small, specific use case for the developers, it is also easier for them to understand the code. Legacy systems, however, end up being a headache because of their millions of code lines and dependencies.
• Efficiency: From a project management perspective, we can also take this point into account. Because APIs have less code and their functionality is so specific, the time to deliver new features can be shortened compared to other architecture types or legacy systems.
• Reusability: As we mentioned earlier, we want to create an application network that connects all of our APIs to bring together a system that covers our needs. Since APIs are so small and functionality-specific, they are created with reusability in mind. The output response depends on the input request it receives. This is helpful to reuse specific functionality that is consumed by several services or systems and there’s no need to create custom code since they’re loosely coupled.

Everything comes together. After understanding all of the previous concepts – no-/low-code technologies, integrations, and APIs – we can start talking about MuleSoft. In this section, we’ll describe what MuleSoft is, what some of its products are, how it’s useful, and how it is going to help you in your career as a Salesforce developer. First of all, MuleSoft is the name of the company that created the existing suite of products. When people talk about MuleSoft in a development context, they are referring to all of the products that this company has created. A clearer example of this can be seen now that Facebook has changed its name to Meta; we can more easily see the difference between the name of the company (Meta) and its corresponding products (Facebook, Instagram, and WhatsApp). The same is the case with MuleSoft. The name of the company is MuleSoft; it’s not the name of a product. But when we refer to MuleSoft, it encompasses all of MuleSoft’s products.

Listing MuleSoft’s products

Let’s take a look at some of the most popular products that MuleSoft has released so far (up to the time of writing this book). The suite of technologies can be broken down into three main products:

• Anypoint Platform
• Anypoint Studio
• Composer

Each of these products includes its own products and functionality as well. Let’s review them in detail.

Note

There are more products on the way – such as MuleSoft Robotic Process Automation (RPA) and Anypoint Code Builder – but we will not be talking about those in this book since they’re either not publicly available yet or have been just released.

Anypoint Platform

Anypoint Platform can be accessed through your browser. If you go to anypoint.mulesoft.com, you will see the login screen. You can create a free trial account that will last 30 days. Inside Anypoint Platform, you will find the following products:

Note

We will talk more about all these products in Chapter 5, All about Anypoint Platform.

• Anypoint Design Center: This is where you can manage your API specifications with API Designer and your Async API Specifications with AsyncAPI Designer and create quick Mule applications with Flow Designer.
• Anypoint Exchange: You can look at this product as an app store of sorts where you can find a catalog of published assets that you can reuse in your own code.
• Anypoint DataGraph: If you’re familiar with DataGraph, MuleSoft created its own product to help you use this technology within its suite of products.
• Access Management: This is where mostly only the admins of the account will be able to change permissions or access for the users of the account.
• Anypoint API Manager: As its name says, you will be able to manage your APIs from here. You can manage alerts, contracts, policies, SLA tiers, and other settings.
• Anypoint Runtime Manager: The Mule applications are located in Runtime Manager. You can access logs, object stores, queues, schedules, and settings.
• CloudHub: If your Mule application is running within MuleSoft’s cloud provider service, that means you’re using CloudHub. Your Anypoint Platform free account will use CloudHub by default.
• Anypoint Visualizer: You can use this product to get a visual representation of your systems, such as autogenerated architectural diagrams or available policies, or perform some general troubleshooting of your applications.
• Anypoint Monitoring: Here, you can generate custom dashboards or use the built-in dashboards to get a better feel for how your apps are behaving.
• Secrets Manager: Here, you can store sensitive data such as passwords, tokens, certificates, or keys in Secrets Manager so they can be accessed and still be secured.
• Anypoint Runtime Fabric: This is not included in your free trial account, but this is where you would be able to deploy your Mule applications to different cloud providers, such as Microsoft Azure, Amazon Web Services, or Google Cloud Platform.
• Anypoint MQ: This is MuleSoft’s message queueing service. It is a built-in solution that includes its own connectors to use within your code with no extra drivers or settings needed.
• Anypoint Service Mesh: This is not included in your free trial account, but with this product, you can manage non-Mule applications within the same suite of products, regardless of the programming language they’re based in.
• Anypoint Flex Gateway: With this lightweight gateway, you can manage Mule and non-Mule applications. You can install Flex Gateway in Docker, Kubernetes, or Linux. This is included in your free trial account.
• Anypoint API Governance: Here, you can create standards for your API specifications, Mule or non-Mule applications, security policies, and more. This is included in your free trial account.

Let’s now see the products inside Anypoint Studio.

Anypoint Studio

Anypoint Studio is MuleSoft’s IDE (based on Eclipse). You install this application on your computer and this is where you’re able to develop Mule applications. Studio has a nice GUI to find predefined connectors and use them to develop your Mule flows. Inside Anypoint Studio, you will find the following products:

• MUnit: MuleSoft’s testing framework. MUnit is optimized to create tests visually. We can create tests using connectors such as Mock, Assert, and Spy. We will talk more about MUnit in Chapter 11, Testing Your Application.
• APIkit: With this product, you can take your API specification and create a basic structure for your Mule application instead of doing it from scratch. We will talk more about APIkit in Chapter 8, Building Your Mule Application.
• DataWeave: MuleSoft’s functional programming language, optimized for transformations. We will do a deep dive into this language in Chapter 6, Learning DataWeave, and Chapter 7, Transforming with DataWeave.

Let’s now see an overview of Composer.

Composer

Composer, as opposed to the other MuleSoft products, is a no-code tool. There’s no need to create an API specification or implementation. Composer was specifically designed to have clicks not code, as its slogan says. If you’re familiar with some of the no-code tools we mentioned earlier in this chapter, such as Zapier and IFTTT, Composer follows a similar approach. We will talk more about Composer in Chapter 12, MuleSoft Integration with Salesforce.

Now that we understand the variety of products MuleSoft offers, let’s look into how all of these tools are useful.

Understanding why MuleSoft is useful

We just learned about the suite of products and functionality that MuleSoft offers. Besides being a low-code technology with a smaller learning curve than a regular programming language, MuleSoft can fulfill almost all the requirements you need to cover in the development life cycle. From designing to implementing and testing, to deploying, securing, and monitoring your solutions, MuleSoft most likely has a product for your needs. The best part is that because you’re using all these products under the same sphere, they can be easily integrated or moved from one stage to the next.

Let’s review what a Mule application or an API life cycle would look like within MuleSoft’s products.

Design phase – API specification

We’re first going to review what MuleSoft products can be used in the design phase of your API. This will result in an API specification that you can use as the foundation for the next phase. This phase takes place in Anypoint Platform:

1. API specification design: Using Design Center, you can start designing your API specification with the visual API Designer without having to know RESTful API Modeling Language (RAML) or OpenAPI Specification (OAS).
2. API specification testing: Using the mocking service, which can be found in API Designer, you can create a mock of your current API specification and make calls to it. This is with the purpose of getting a feel for how the developers will experience your API before even implementing it. The idea is that you go back and forth between the design and testing until you feel comfortable with the specification you’ve created.
3. API specification publishing and feedback: From API Designer, you can publish your finished specification to Exchange for others in your organization to discover. Exchange will automatically generate basic documentation based on your API specification. You can share this Exchange asset with others in order to gather feedback on your design. If you still need to adjust things, you can just go back to API Designer and modify what’s needed. After you do this, you can publish a new version of your API specification in Exchange.

We can iterate through these first three steps as long as needed until we feel comfortable that we have an API specification on which to base our implementation. Once we have the first draft, we can continue with the next phase.

Implementation phase – Mule application

Now that we have a first draft of the API specification, we can get started with the implementation. This phase takes place in Anypoint Studio:

1. Mule application implementation: This process is where you would be using the available connectors or DataWeave to start creating your Mule application’s implementation. After you’ve finished any number of iterations and feel comfortable with the API specification you generated in the previous phase, you are now ready to start creating your Mule application. From Anypoint Studio, you can connect to your Anypoint Platform account and download the API specification from Exchange. This will generate the basic flows and error handling so you don’t have to start creating everything from scratch. This process uses APIkit to route the different types of requests to their corresponding Mule flows. In addition, any request that is not recognized by the API specification will be routed to the corresponding error handling. For example, if we refer to our previous restaurant analogy, if you were to order food that was not available on the menu, the server would respond that what you requested does not exist.
2. Mule application testing: Once you generate the main functionality, you are ready for the next step, which is where you would start creating your unit testing using MUnit. Nothing is better than a high-quality application. Here, you can create mocks and use asserts to make sure the different scenarios for your code are indeed working as expected. A best practice is to aim for 90% of MUnit coverage, if not 100%, but this varies depending on each project.

Same as earlier, we can iterate through these steps as many times as we need to achieve good-quality code and functionality of the application. Once we’re happy with the first draft of the functioning app, we can continue with the next phase.

Deployment and managing phase – API

Now that we have a functioning Mule application, we can start the deployment and managing phase. This phase takes place in Anypoint Platform:

1. API deployment: After you’ve implemented and tested the Mule application on your local machine, you are ready to deploy it to the cloud. You can deploy your application from Anypoint Studio directly to Anypoint Platform. Just a few clicks and we’re done. You can see the progress of this deployment from Runtime Manager. You can host your app in different cloud providers, such as Amazon, Microsoft, or Google; but for now, we’ll just focus on MuleSoft’s CloudHub.
2. API security: Now that your application is running in CloudHub, you are ready to create API policies, contracts, SLA tiers, and so on. All of this is managed by API Manager.
3. API monitoring: Your API is secured and running. Now it’s time to lay back and relax. You can monitor your API from Anypoint Monitoring or create alerts in case something goes wrong and you want to immediately get notified about it.

The whole life cycle doesn’t end there, of course. This is just an example of what an API life cycle could look like. After deploying the application, the cycle starts again. Once the developers get a hold of your API and start testing it, some features or bugs will be on their way to you. This is where we’ll restart the cycle from the design or implementation phase, depending on the case, and the cycle continues once again.

Now we have a better idea of what MuleSoft is and how it’s useful in the API life cycle. This book was written for Salesforce developers and architects, so let’s now see how MuleSoft is helpful for your professional career.

Analyzing how MuleSoft helps Salesforce developers

MuleSoft has long been helpful in integrating different technologies, including Salesforce. However, since Salesforce acquired MuleSoft, we can see more and more integrations between the technologies. Furthermore, the acquisitions of Slack, Tableau, and Servicetrace have also increased the use of MuleSoft throughout these platforms and vice versa. For example, there wasn’t an official Slack connector in MuleSoft before, but one was created after the official acquisition. There is also a new product in the works called MuleSoft RPA, and guess what Servicetrace is? Yes, it’s an RPA technology. We now also have Composer, which is a technology created by mixing both Salesforce and MuleSoft technologies.

While it might be true that you don’t necessarily need to know MuleSoft in order to be a Salesforce developer, the past and the present are the foundation of what we predict the future will be like. What history’s been telling us is that Salesforce will continue adding to its 360 products from other companies it acquires. We already have Composer in common between Salesforce and MuleSoft – who knows what else will be integrated in the future. But it all points to the fact that MuleSoft will be integrated more and more to the Salesforce suite.

From a professional career perspective, currently, there are not a lot of developers who are proficient in both MuleSoft and Salesforce – they are either Salesforce developers or MuleSoft developers, or they may know a little bit about the other but are not experienced developers in both. It wouldn’t be a surprise if in some years job postings started requiring proficiency in both technologies.

The following summarizes what we have discussed in this section:

• MuleSoft is slowly being added to Salesforce’s technology suite
• There is already a product created that combines both Salesforce and MuleSoft: Composer
• Career-wise, it would be smart of you to get ahead of the trend and become proficient in both technologies before it becomes a requirement

This is where it all comes together. We understand that MuleSoft is a collection of low-code technologies that help us create APIs or microservices based on Mule applications. Integrations are important because we can connect different services with different data types or structures to create an application network.

Understanding what application networks are

Why do we create several APIs and connect them instead of creating one single system to do all of this? Remember the benefits of using APIs: loosely coupled, governance, discoverability, easier maintenance, efficiency, and reusability. We can’t achieve these with a regular system. All the code is tightly coupled, it’s hard to maintain, it can’t be reused, and so on. This is why we want to create an application network to connect all of these different building blocks.

Figure 1.4 – Application network representation

We can connect services or platforms such as Salesforce, Workday, Amazon Web Services, NetSuite, Dropbox, Google Drive, SAP, and Twitter – the options are endless. Even if these don’t have an API to connect to as easily, MuleSoft’s products offer so many options for customization that you can really integrate almost anything with MuleSoft. The main vision when MuleSoft was created was to be able to work together and make more APIs to discover and reuse. This would essentially reduce time to delivery and IT demands would be easier to meet over time. But how exactly do we plan on doing this network? This brings us to our next point.

Analyzing the API-led connectivity approach

MuleSoft believes in an architectural approach in which you have a standard to give your APIs a specific purpose in your application network. This can help you create more reusability around your APIs so you can easily add new functionality or APIs, modify or upgrade existing ones, or remove any API that’s no longer being used.

This API-led connectivity approach is based on three different layers in which we’ll categorize our APIs: Experience, Process, and System.

Figure 1.5 – The three layers of the API-led connectivity approach: Experience, Process, and System

Experience layer

This is the top layer. It is where we have the APIs that directly make contact with the client application, whether that’s a mobile application or a desktop application. This is where we put the APIs that have direct contact with the outside world, that is, the APIs that are public. The sole purpose of these Experience APIs is to connect to the client application and send the information to the next layer. The only logic we may add here is any kind of security or filter to make sure the information that is received is correct and can indeed proceed with the rest of our application network. If anything is missing or looks suspicious, then it’s the Experience API’s responsibility to not let this data proceed further and raise this as an error immediately.

Process layer

This is the middle layer. It is where we, as its name suggests, process or transform the data we received from the Experience layer in order to be sent to the rest of the APIs. Just as we saw earlier on in this chapter when we talked about integrations, if we have system A, which processes certain information, and then we have system B with a different data structure, then it’d be the responsibility of the Process APIs to transform (or translate) these two data types in order to be understandable by their corresponding APIs.

Going back to our previous example, say now system A is the data that comes from the client application and system B is the data that we need to send to the server application; we end up with something like this:

client-application.json

{
"ID": 1,
"FirstName": "Alexandra",
"LastName": "Martinez"
}

server-application.json

{
"id": 1,
"firstName": "Alexandra",
"lastName": "Martinez"
}

It is the Process API’s responsibility to do these two transformations both upstream and downstream. The Process API would first receive client-application.json as its input, then it would have to transform it to the server-application.json structure and send it to the corresponding API. After the downstream API responds, the Process API needs to transform the data from whatever it received from the server application to whatever data type or structure the client application is expecting to receive. In this case, the client application would be the Experience API that’s calling the Process API, and the server application would be the System API.

System layer

This is the last layer. The Experience layer, the topmost layer, is the one that directly connects to the client application. Now that we’re at the bottom, this is where we directly connect to the server application, whether that is Salesforce, Facebook, SQL, or Azure, you name it. These APIs are where we store any tokens, passwords, credentials, or URLs that are needed to connect to the underlying systems.

Since most of the filtering, security, cleanup, and transformations are done in the previous layers, this layer can focus solely on connecting and sending the data to its target. If there is more data transformation needed from this response, the Process API is responsible for doing so, not the System API.

We have a better picture now of how the API-led connectivity approach is helpful for our application network – when we separate the APIs into these three layers, we have a better standard to follow in our architecture. Now, let’s summarize all we have learned in this chapter.

In this chapter, we learned how the learning curve for no-code or low-code technologies is smaller than learning a programming language. You mainly need to learn how to use the GUI, which may take some hours or days, and almost all the functionality is done through clicks instead of code.

When we have systems that need to exchange pieces of information, but they don’t necessarily use the same data type or data structure, we create integrations to help translate this data. Using APIs is better for the developers who create or maintain the code, the developers who want to use a public API, and the companies behind them. APIs, as opposed to other systems, are loosely coupled, easier to maintain, discoverable, and reusable.

MuleSoft’s products three main products are Anypoint Platform, Anypoint Studio, and Composer. Anypoint Platform is a tool you can access from your browser to design, deploy, manage, secure, and monitor your APIs or applications. Anypoint Studio is the IDE you download and install on your local computer to develop and test your Mule applications. Finally, Composer is a no-code product that was created by mixing both Salesforce and MuleSoft to help you integrate your systems faster.

The whole reason for creating APIs in the first place is that it makes it easier to have an application network made of smaller pieces that we can connect as building blocks. We can reuse the functionality for different purposes, instead of having to create custom code with the same functionality.

MuleSoft believes in using the API-led connectivity approach as the architecture pattern to connect our APIs. We have the Experience, Process, and System layers, which will help us create specific APIs that can be reused and maintained more easily throughout the application network: the Experience layer for client application-facing functionality, the Process layer for orchestrating and processing the information, and the System layer for connecting to external services.

In the next chapter, we will expand our API knowledge from the basics to the technical aspects. We’ll review some best practices to design a better API specification and understand how exactly APIs connect with each other.

Take a moment to answer the following questions to serve as a recap of what you just learned in this chapter:

1. What’s the difference between no-code and low-code technologies?
2. What are the API components we talked about in this chapter?
3. How do the API components relate to the API analogy we discussed?
4. What are the names of the three main MuleSoft products?
5. List some of the products or functionality that can be found inside those three main MuleSoft products.
6. What are the three phases we talked about when creating an API within MuleSoft?
7. What are the three API-led connectivity layers?
8. What purpose does each of the API-led connectivity layers serve?

1. The difference between no-code and low-code technologies are:
   • No-code technologies provide a user interface for you to use the product and don’t require you to learn or know any type of programming language in order to use it.
   • Low-code technologies also provide a user interface, but they do involve some minor programming in order to create more personalized functionality. Although the use of the technology doesn’t revolve around the programming language, it is a part of it.
2. The API components are as follows:
   • Implementation: The body of the API, where all the information is processed
   • Request: The data you send to the API with detailed information
   • Response: The data you receive back from the API with detailed information about what happened with your request
   • API specification: The standard, or contract, so you know what you can ask for in the request and what you might receive in the response
3. The API components relate to the API analogy as follows:
   • The implementation is like the kitchen staff: they receive your order, cook your food, and serve your order. You don’t know how they cooked it or exactly what ingredients it has, but you receive what you requested.
   • The request is what you order, with any specific details, such as a hamburger with no tomatoes, extra pickles, in a combo, with an orange soda, and fries on the side.
   • The response is what you get back after you made your order, such as a hamburger with no tomatoes, extra pickles, and so on.
   • The API specification is like the menu when you arrive at the restaurant. You can’t just order whatever you want; you have to order available dishes from the menu.
4. Anypoint Platform, Anypoint Studio, and Composer
5. The products or functionality that can be found inside the three main MuleSoft products are:
   • Anypoint Platform:
     • Anypoint Design Center
     • Anypoint Exchange
     • Anypoint DataGraph
     • Access Management
     • Anypoint API Manager
     • Anypoint Runtime Manager
     • CloudHub
     • Anypoint Visualizer
     • Anypoint Monitoring
     • Secrets Manager
     • Anypoint Runtime Fabric
     • Anypoint MQ
     • Anypoint Service Mesh
     • Anypoint Flex Gateway
   • Anypoint Studio:
     • MUnit
     • APIkit
     • DataWeave
   • Composer
6. Design phase, implementation phase, and deployment and managing phase.
7. Experience layer, Process layer, and System layer.
8. The purpose served by the API-led connectivity layers are:
   1. Experience layer: The APIs that are exposed to the calling clients, such as a mobile application, a web application, or a desktop application. This is where you’d add any public-facing security, such as appropriate security policies.
   2. Process layer: The APIs that are in charge of orchestrating and processing the data. They receive the data from the Experience APIs, process it, and send it to the System APIs. Then they receive the data from the System APIs, process it, and send it back to the Experience APIs. This is where all the data transformation should take place.
   3. System layer: The APIs that connect to any downstream or external systems. Their sole purpose is to connect with external technologies and send back – to the Process APIs – the information that was received. This is where all the external systems’ credentials are stored.