Currently, the dynamic development of customers’ increasing needs sometimes requires that more advanced solutions be employed in our applications. Let’s imagine that we are building a dashboard where you want to have data that’s automatically updated from the backend. Or, maybe you’re thinking about a system that’s related to stock exchange topics. Mendix provides certain out-of-the-box solutions which can be used to build a dashboard like this and enables customisations to be made.
In this article, I’ll show you four methods which you can use to add real-time elements to your app. Each presented approach is different and has specific pros and cons. You should choose an approach that will best meet your business needs. So, let’s get started!
The Fastest Solution
Use the scheduled events and microflow timer.
If we want to refresh our data without any user actions, we can use a timer widget to execute the microflow or nanoflow for each defined period. This is a super quick solution: download the widget, put it inside the page context, and done! You’re ready to start fetching.
Unfortunately, this solution has some cons: the action is executed even if nothing changed in our database – so it’s not the smartest solution. Each microflow or nanoflow call with Retrieve executes a call to the Mendix runtime and database. In the case of thousands of clients, this could create some performance issues.
- Easy to implement,
- Doesn’t require custom code.
- Arrange runtime,
- High HTTP traffic,
- Possible negative performance impact,
- Unnecessary calls when nothing changed.
The Client-Side Solution
Use nanoflow with JS action to fetch the data.
In this solution, we can apply several approaches: a call to the external API or a call to our own API. We can also extend our solution by using design patterns that will reduce the number of hits to the backend. As an example, we can add a caching layer and move HTTP calls to this layer.
- Move some of the workload to the client-side,
- Gives the possibility to display data directly from an external API.
- Generates high HTTP traffic,
- Unnecessary calls when nothing changed,
The Smarter Solution with Socket.IO
Update data only when it has changed.
To implement this, you should build a minimal service – an emitter. The emitter needs to handle the POST request and emit data to your clients. I did this using Node.js.
It’s quite smart. Let’s dive deeper into the technology execution stack. We know that Socket.IO uses long polling. So, the HTTP traffic is still quite high but it’s still a smarter solution than an API call in the infinity loop.
If you want to build your service, use the Node.js code attached below. To consume this, just create a simple React.js component with socket.io-client:
- Fetch only when data has changed,
- Data is fetched immediately when changed.
- Requires a custom service – an emitter,
- It’s not an entirely low-code solution,
- Requires creating and maintaining an external service.
No Coding Necessary
Update only when the data has changed – without coding.
If you don’t want to code your external microservice, you can use a configurable service like Firebase. It offers you a real-time database which works perfectly with React.js – there’s a connector that connects React.js to Firebase. To use it in Mendix, you should take additional steps. We did this for you and prepared a widget that you can use. It’s available on the Mendix App Store.
You just need to install the mentioned widget and put your Firebase configuration scripts into our widget configuration. Make sure that you set proper writing rules in the Firebase console to make sure that nobody overwrites your data!
I have two tips for you regarding this widget:
- Configure all attributes as constants,
If you use it for many fields, just copy and paste the configured widget to skip having to choose all the authentication parameters again.
- Fetch only when data has changed,
- Data is fetched immediately when changed,
- Firebase is an auto-scaling solution,
- Quick to develop with the widget, no coding required.
- Having to add an external dependency to your application.
You can deal with a real-time challenge in several ways. It’s important to remember that the technology of the solution should be chosen based on how effectively it will support business requirements.
To make an informed decision, you should first answer certain questions:
- What’s the expected number of users?
- Should it be an auto-scaling solution?
- What’s my budget?
- When is the deadline?
- Do I have JS coders in my team?
If you build an app dedicated to a limited number of users, and you want to implement it quickly – just choose the first solution. But, remember that if the number of users increases, the application’s performance could be affected. If you need a more elegant solution in a small app and you have JS coders on board, you should consider the second solution.
Lastly, if you’re open to extending your application with additional services, you can consider the third or fourth solution (depending on if you want to code or not).
For more information, download Objectivity’s latest white paper on low-code: “Gain more by doing less”.