Exploring application networks and the API-led connectivity approach
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.
