This is part four of my five-part series documenting high scalability in Mule 4. If you haven’t read part one, Scale your APIs with Mule 4, part two, Reactive programming in Mule 4, and part three, Thread management and auto-tuning in Mule 4, check them out! This post will cover streaming in Mule 4.
Once upon a time, I couldn’t do without my middleware. To make my application resilient and scalable, and to allow it to talk to everything else in the enterprise, I had no choice but to stand up an ESB in my architecture. It was literally in the middle of everything I did. Then, when I moved to the cloud, my world began to change.
Salesforce introduced Platform Events with its Summer ‘17 release (API v40). While the Anypoint Connector for Salesforce has supported Streaming API Events, the following description from Salesforce might be helpful to understand the difference between Platform Events and Streaming API Events.
Streaming in Mule 4 is now as easy as drinking beer!
There are incredible improvements in the way that Mule 4 enables you to process, access, transform, and stream data. For streaming specifically, Mule 4 enables multiple parallel data reads without side effects and without the user caching that data in memory first.
Salesforce introduced the Streaming API with its Spring ‘16 release (API v36). It was a neat feature since Salesforce users don’t have to poll or periodically call Salesforce to check any updates in their objects. One important limitation with API v36 was that the Streaming API (API v36) doesn’t guarantee durability and reliable delivery of notifications. However, Salesforce added message reliability and message durability in its API v37. We are excited to announce the release of Salesforce Connector v8.0.0 which supports the Durable Streaming API.
When it comes to getting data in and out of Salesforce using Anypoint Platform, there are a number of different options. Typically, using just one of them won’t give you everything you need and you might have to combine a number of them to to achieve a complete solution. In this post, we’ll summarize 4 options – Realtime, Custom, Bulk, and Data Virtualization – when to use which, and things to keep in mind for each.
We are all very proud to announce that Mule’s December 2013 release shipped with a major leap forward feature that will massively change and simplify Mule’s user experience for both SaaS and On-Premise users. Yes, we are talking about the new Batch jobs. If you need to handle massive amounts of data, or you’re longing for record based reporting and error handling, or even if you are all about resilience and reliability with parallel processing,
Myself and Dave recently spoke a different events about Real-time APIs and use cases. Folks have been asking for the slides and video, so here they are!
The number of real-time APIs on the Web are rising. What the heck are real-time APIs, how are they used? How are they built? This deck and demo was presented at CloudMafia in San Francisco.
Before streaming APIs, if you wanted to know if there were any updates on a specific event you had to query the API periodically and check if updates indeed occurred. Most likely, many of these queries would probably return no results as no new event happened but still resources were consumed in the process including the API call and parsing the response. Now, what if you want to get notified not only of 1 event but 10,
Its about time the Web became more event-driven. We have had AJAX for many years enabling events between server and browser, but on the backend we are still polling data. With the explosion of public APIs from SaaS, Social Media and Infrastructure Apps, more and more applications are written by composing web APIs. Developers often need to call a API to get data updates, only to find that nothing has changed. Streaming APIs provide a more elegant solution to polling allowing developers to subscribe to changes they are interested in.
