As a Mendix Expert, I often encounter scenarios where the decision to asynchronise processes can significantly impact the performance, reliability, and user experience of an application.
This blog post aims to shed light on the importance of asynchronous processing, specifically focusing on Queueing in Mendix.
Author of the blog:
Chelsea Veenstra
At the start of May 2024, Chelsea joined our ranks, and we couldn’t be more thrilled. With pride, we announce that Chelsea is the sole Mendix Certified Expert in Australia, bringing unparalleled expertise to our projects.
Understanding Asynchronous Processing
In software development, asynchronous processing allows tasks to run in the background, enabling the main application to continue functioning without waiting for these tasks to complete. This is particularly useful for handling long-running processes, improving responsiveness, and managing resource-intensive operations.
However, asynchronous processing is not always the best choice. It should not be used when tasks depend on the immediate completion of other tasks, as this can lead to complex dependency chains and difficult-to-debug issues. For instance, in cases where sequential processing is crucial, such as in financial transactions where the order of operations must be preserved to maintain data integrity, synchronous processing is preferable.
Additionally, for tasks that require real-time user interaction and feedback, such as form submissions or interactive applications, synchronous processing ensures immediate results and a better user experience. Finally, asynchronous processing can introduce complexity in error handling and state management, making it less suitable for simpler applications where such overhead is unnecessary.
Why Asynchronise?
Improved Performance:
- Non-blocking Operations: By delegating time-consuming tasks to background processes, the main application stays responsive, ensuring a seamless user experience with real-time interactions. Also without user interaction, asynchronization plays a crucial role. It allows the application to manage its own processing capacity, handling messages at a controlled pace rather than being overwhelmed by an uncontrolled input.
- Resource Management: Asynchronous processing allows for better resource utilization, as tasks can be executed when system resources are available, preventing bottlenecks.
Scalability:
- Handling High Loads: In scenarios where applications need to be able to process high loads, synchronous processing can lead to congestion. Asynchronous processing, on the other hand, distributes the load more evenly, making it easier to scale applications.
- Distributed Systems: For applications that rely on multiple microservices or external systems, asynchronous communication ensures that the failure or delay in one service does not bring down the entire system.
Error Handling and Reliability:
- Graceful Degradation: If an asynchronous task fails, the main application can continue to function, and the error can be handled or retried without affecting the user experience.
- Retry Mechanisms: Asynchronous processing often includes built-in retry mechanisms, ensuring tasks are eventually completed even if they initially fail due to temporary issues.
Implementing Queueing in Mendix
To implement message queueing in Mendix, follow these steps:
Setting Up the Queue:
- Add a task queue to your model and specify the number of threads for processing queued messages.
- Chelsea’s Tip: Start with one thread to see if it efficiently handles the queue. If additional capacity is needed, gradually increase the number of threads. This approach helps prevent application crashes by avoiding sudden increases in resource usage.
Producing Messages:
- Identify the tasks that can be offloaded to the queue. These could be long-running processes, processing incoming messages, external API calls, or any operation that should not block the main application flow or users interacting with the application.
- Chelsea’s Tip: Create a persistent entity to use as an input for the processing microflow. This entity can include attributes such as trackingID, payload, processedTime, and isFailed. Additionally, set up an overview page for this entity so you can easily track and review messages, especially when something goes wrong with your application. Unlike the TasksQueue Helper module, which provides an overview of the actual tasks and their retries but lacks insight into the context of the tasks being processed, this approach ensures you have full visibility into the details of each task.
Consuming Messages:
- Set up a microflow to process messages from the queue. This microflow should handle the processing logic for the messages.
- Create a call microflow activity after you’ve created your input entity, where you select the processing microflow. Open the call microflow activity and select, Execute this microflow in a Tasks Queue. Select the queue you created.
- Chelsea’s Tip: In the processing microflow, update the processedTime and isFailed attributes with the correct information. This way, you maintain a complete overview of what happened to your message.
Monitoring and Management:
- Use the Task Queue Helper module to monitor your queues. This module provides insights into the number of tasks in a queue, the number of tasks yet to be processed, and any retries that have occurred.
- Implement clear logging messages to track the processing of tasks. This will aid in troubleshooting by providing detailed information when issues arise.
- Chelsea’s Tip: Add the trackingID of the message to your log entries. This allows you to easily trace the context of any problems that arise. Additionally, I recommend building a retry mechanism on the overview page of your custom persistent entity. This can be used, for example, when there is a bug in your application. After deploying a hotfix, you can use the retry mechanism to reprocess the failed messages.
Conclusion
Asynchronous processing through message queueing is a powerful technique for enhancing the performance, scalability, and reliability of Mendix applications. By decoupling components, ensuring reliable message delivery, and enabling efficient resource utilization, message queueing allows developers to build robust and scalable applications.
So, to asynchronize or not to asynchronize? In the context of Mendix and modern application development, the answer is clear. Embrace asynchronous processing and leverage message queueing to build responsive, scalable, and reliable applications.
Learn more
Learn more about how we can help your company. Visit our services page for more details.
Schedule a no-obligation conversation or join our “App-in-a-morning” session, where we demonstrate the power and speed of developing applications in Mendix.
Make the future happen with CAPE.
Chelsea Veenstra
CAPE & Mendix
At CAPE, we’ve empowered numerous companies with self-enablement, guiding them right from the outset. From establishing foundational elements to strategizing complexities and architecture, we ensure that your team is well-equipped to embark on its low-code development journey.
Our comprehensive approach includes hands-on training for your employees, ensuring they possess the skills and knowledge necessary to kickstart your own in-house development team. With our support, you’ll be fully prepared to leverage the Mendix Best Practice Bot and other powerful features, propelling your organization towards efficient and independent app development.
More Mendix tips
Forget Gold and Diamonds
Articles Forget Gold and Diamonds - Feedback Is the Real Treasure Mendix Mini survey In this blog What are Mini Surveys? How to implement Mini Surveys A small plot twist… Final Thoughts More mendix tips If you’re building applications, you...
Online-First, Offline-Smart: 4 Lessons learned from a Hybrid Mendix App
Articles Online-First, Offline-Smart 4 Lessons learned from a Hybrid Mendix App In this blog Lesson 1: Architectural Foundation: Keep It Light Lesson 2: Automating Sync Between Online and Offline Lesson 3: Switching Profiles: Online ↔ Offline...
Why Low-Code (Mendix) isn’t a Japanese knife, and that’s a good thing
Articles Why Low-Code (Mendix) isn’t a Japanese knife and that’s a good thing In this blog Do you always need the best of the best? The problem with the "Japanese Knife" approach Low-code is more like a German steel knife AI and low-code: a...