Scale Your API Programs With Mule 4
This article explores Mule 4 and how to to scale your API programs with Mule 4.
Join the DZone community and get the full member experience.Join For Free
Mule developers build integration solutions that must cater to high volumes of real-time and batch data. In some cases, the size of payloads can be larger than memory. In others, API solutions may have to handle high rates of API calls per second.
Horizontal scalability, whereby Mule instances are deployed across multiple virtual and physical machines, is costly. Thus, a single Mule instance must utilize to the maximum underlying processing and storage resources as it handles traffic. Its ability to handle more traffic with more underlying resources is what we refer to as vertical scalability.
Mule 4 addresses vertical scalability with a radically different design using reactive programming at its core. With the aim to maximize throughput, our engineers have focused their efforts on achieving higher concurrency through non-blocking operations and a much more efficient use of CPU, memory, and disk space.
What Is Mule 4?
Mule 4 is the newest version of Mule runtime engine that uses reactive programming to greatly enhance scalability. A Mule application is an integration application that incorporates areas of logic that are essential to integration. These logical domains include:
- Error Handling
A Mule application is developed declaratively as a set of flows. Each flow is a chain of event processors. An event processor processes data passing through the flow with logic from one of the said domains. Mule 4 uses reactive programming to facilitate non-blocking execution of the event processors. This has a significant impact on a Mule application's ability to scale the number of events it can handle concurrently. Each event processor belongs to a module. Modules are added to Mule runtime engine as required by Mule applications. Mule 4 is entirely extensible through custom modules. The Mule SDK, a new addition to the Mule 4 ecosystem, enables you to extend Mule with new modules. Custom modules benefit from the same scalable reactive capabilities of the Mule runtime engine.
The advent of single page web apps and native mobile apps has fueled users' appetite for fast and responsive applications. We want data to be made available now. We have become accustomed to push notifications. Architectures in the back-end have evolved to cater to front-end responsiveness and drive elasticity and resiliency through event-driven microservices. Reporting requirements have evolved from entirely retrospective analysis to include real-time predictive analytics made possible by event stream processing.
Reactive Programming (Rx) arose in the .Net community to give engineers the tools and frameworks needed to cater to this appetite; it quickly spread to other languages. It became JavaRx in the Java world, and Spring has fully embraced it with Project Reactor. Reactor now lies at the heart of Mule 4's internal architecture.
Reactive merges the best from the Iterator and Observer design patterns and functional programming. The Iterator pattern gives the consumer power and control over when to consume data. The Observer pattern is the opposite; it gives the publisher power over when to push data. Reactive combines the two to get the beauty of data being pushed to the subscriber when it is available but in a way that protects the subscriber from being overwhelmed. The functional aspect is declarative. You can compare the functional composition of operations to the declarative power of SQL, the difference being that you query and filter data in real-time against the stream of events as they arrive. This approach of chaining operators together avoids the callback hell that has emerged in asynchronous programming and that makes such code hard to write and maintain.
Spring Reactor Flux
The Flux API represents a stream of events. We create a flux from the array of words: ["the", "quick", "brown", "fox", "jumped", "over", "the", "lazy", "dog"]. As we process each word in the array, we form another flux from all the letters in the word and merge each new flux into one for all the words using the .flatMap()operation. We then purge out repeating letters, sort them, and merge them with a flux of incrementing integers [ "1. a", "2. b", ... ] using the .zipWith()operation.
A key takeaway is that all of the above is declarative. Through functional composition, we can declare how we want processing to be done without actually implementing it. But nothing happens till we subscribe. Subscribing to the final flux produces the stream of strings we see in the output.
In my next post, I'll dive deeper into reactive programming and non-blocking code execution in Mule 4. You can try Mule 4 today and download our whitepaper, Reactive programming: Foundations for high scalability in Mule 4, to get started.
Published at DZone with permission of Nial Darbey, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.