Nowadays, writing an application using a monolithic project is still an option but not the best for most applications I prefer using microservices and APIs since they're more versatile and not coupled to a single technology among many other advantages. However, for an application that uses several APIs, external and internal, the maintenance at some point could be difficult for developers, but not impossible.
Some months ago I found out about MuleSoft, which one of its goals was to solve this problem using a new development approach they call Application Networks and API-led connectivity.
Application networks and API-led connectivityThe premise is this. Since technology is growing so fast, generally the IT department
doesn't have enough time to catch up and there's an important gap between the IT delivery
capacity and the IT demand.
To close this gap, the MuleSoft team devised a new IT operating model emphasizing Consumption.
Here is when API-led connectivity and Application Networks come in. The API-led connectivity
is the enabler and the Application Network the design.
To accomplish this connectivity, MuleSoft suggest to break down the APIs into 3 classifications:
- System APIs: Exposes the organization assets, such as database resources and third-party services (Salesforce, SAP, AWS, Box … )
- Process APIs: Reuses those assets for the organization processes composing the information
- Experience APIs: basically the “Frontend” of the Backend, reuse and consume the APIs
Center for Enablement (C4E)
It is the team in charge of publishing and maintaining all the Assets for the rest of the APIs,
it is supposed to be in the middle of the organization.
Application networkFor a project following the API-led approach, some Assets should be published and visible.
If another project comes up, it is not necessary for their developers to expose again the same
Assets, they just need to grab the ones that are already exposed and add to it by publishing
more if necessary. This happens every time a new project is developed- That's how an application
network is being created, by publishing and reusing Assets among them.
For Frontend, we have different models to design our applications and we can use them as we wish based on our needs. However, for Backend, since it is supposed to be easier, it is more difficult to find a design approach/tool that fits what we want to achieve.
MuleSoft's approach is very interesting because it is not only a development model; it is a whole platform that allows us to design our applications, mock our APIs even when they're not implemented yet, create an Application Network for the company where all the resources can be found and implemented easily, manage permissions and get analytics data from each application in real-time.
This is a good alternative to consider next time you start a new project.
