On this website we use cookies that are strictly necessary to make our website function correctly, as well as optional – analytics, performance and/or marketing - cookies which help us improve our website by collecting and reporting information on how the website is used, as well as help us to reach out to you with information about our organization or offer. If you do not wish to accept optional cookies when visiting our website, you may change the settings in the Cookie Settings. For more information go to Cookie Settings.

Skip to content

Bring Real-Time Frontend Solutions to Your Mendix Low-Code App


Jun 8, 2020 - 5 minutes read

Michal Gogol
See all Michal's posts
Data Driven Organisation Blog Ebook 416X300


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.

What about the case when we’re fetching this data from an external API? Do we need to create the server-side action Call Rest Service? No! We can use a JavaScript action inside of a nanoflow, which runs on the client-side for fetching data, then map the result to non-persistent entities. All jobs are executed on the client-side. We can make an API call to the backend. This is still a better performance solution than a microflow in an infinity loop on the server-side.

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.

The code of a JavaScript action with a HTTP GET call attached below:

JavaScript action with a HTTP GET call



  • 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,
  • Requires custom JavaScript code.

The Smarter Solution with Socket.IO

Update data only when it has changed.

To solve the issue in a smarter manner, we need to apply two-way communication between the frontend and the backend. To achieve this, we can use a Socket.IO library. You will find it in an NPM repository. Some JavaScript skills are needed to code this solution from scratch. According to React state management, only changed data is refreshed. The Socket.IO service will emit data only in the case when a client is connected. If nobody is connected, data will not be processed in our emitter service.

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:

Node.js code



  • 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!

Firebase configuration scripts

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”.
Data Driven Organisation Blog Ebook 416X300
Michal Gogol
See all Michal's posts

Related posts

You might be also interested in


Start your project with Objectivity

CTA Pattern - Contact - Middle