MuleSoft Crowd Release vs. Mule 4 Release

MuleSoft Crowd Release and Mule 4 Release have been out for a while. Crowd Release was out around May 2017, and Mule 4 was released at the end of 2017.

Many existing Mule clients have upgraded to the Crowd Release, more new clients have adopted Mule 4. However, even with the rapid adoption, I have noticed many people are still unclear on the differences between the two.

In this post, I’ll highlight the main differences between Crow Release and Mule 4. I’ll highlight some main features in each release. I plan to elaborate more about these features in future posts.

The details of each release are in the release notes. However, sometimes release notes can be hard to read. So here is a glance of the main differences.

Crowd Release

Let’s take a look at Crowd Release first. At the very top, Crowd release is still 3.x.x. To the Mule 3.x users, the most noticeable change is the API manager 2.x, the new Design Center and improved Exchange server. Crowd release now uses API Manager 2.x https://docs.mulesoft.com/api-manager/v/2.x/

Crowd release promotes full life cycle API development and deployment. Here are the main steps to develop an API:

Please note: the following steps are for developing a full API with implementation, not just the API proxy, which is a slightly easier case.

Choosing a Global Software Development Partner to Accelerate Your Digital Strategy

To be successful and outpace the competition, you need a software development partner that excels in exactly the type of digital projects you are now faced with accelerating, and in the most cost effective and optimized way possible.

Get the Guide

Development:

• Step 1: start RAML design in Design Center. It can be RAML fragment (data types etc.) or full API spec.
• Step 2: publish RAML to Exchange
• Step 3: download the API spec from exchange (or directly import it in studio), and develop your API flow as you normally do before.

Deployment:

Before your API can be deployed to Runtime, you need to obtain the parameters for the API auto-discovery (API name and version) from the API Manager (2.x). In the past, you can give arbitrary values (as long as they are unique). Now you have to get these values from the API Manager; otherwise, the API Manager won’t recognize your API.

Please note, APIM 2.x now differentiates between environments for the APIs. This is a major step forward to alleviate the chaotic API versioning headaches with the old APIM 1.x (see https://blogs.perficient.com/2017/10/04/what-is-in-a-mule-api-version/)

Continuing from the development steps above:

• Step 4: grab the API name and version, as shown in the screenshot (on the right side of the API console), add API auto-discovery to your project (<api-platform-gw:api …> tag). As a best practice, store these parameters in the environment specific properties file.
• Step 5: finish the project flows, and deploy to the API to runtime. Now the API Manager 2.x should see the API is running (registered).

Promoting API to Higher Environments

As mentioned above, now APIM 2.x manages APIs per each environment. It also enforces a process to promote the APIs to the higher environments systematically.

To promote an API, from the API Manager console, find your API in DEV environment, you will see a button “Promote from environment.” Follow the screens, it will generate the new parameters (API name, version) for the target (UAT, PROD etc). Copy these parameters, and place them in your environment-specific property files. Now you can deploy your API to the higher environment.

Mule 4:

Mule 4 is a major release. On top of API Manager 2.x (same as in Crow release), it also changed the packaging format to .jar. The project has to be deployed to runtime 4.x. As a side effect, Mule 3.x and Mule 4 projects are no longer compatible with each other.

Mule 4 introduces many other new changes. A few include:

• You have to use Studio 7 to develop Mule 4 project.
• Project is packaged as .jar; project structures are changed, and it heavily leverages YAML for many artifacts.
• Dataweave uses 2.0, which has many new powerful features.
• It supports exception with “try-catch” like Java.
• It comes with enhanced data streaming support, which (supposedly) makes many of the confusing transformers (json-to-object, object-to-json) obsolete.
• Oh, one small but import detail: API auto-discover uses a unique API Id (shown in the screenshot above).

Key Takeaways:

Crow Release still runs on Mule 3.x. It use APIM 2.x, Design Center and Exchange to manage the full API dev-deployment life cycle.

Mule 4 Release is built on top of Crowd release, but it uses Mule 4.x runtime. Besides many new features, you have to use Studio 7, and project is packaged as .jar and project files are no longer compatible between Mule 3.x and 4.x.