Question

Microflows vs Nanoflows – Recommended Architecture Pattern for Production Applications

0

Hi everyone,In modern Mendix applications, especially those built with Atlas UI and responsive web design, nanoflows are frequently used for client-side interactions and improved user experience.However, from an architectural and maintainability perspective, I would like clarification on best practices regarding the separation of concerns between microflows and nanoflows in production-grade applications.Specifically, I would appreciate guidance on the following:In enterprise applications, when should logic strictly remain in microflows instead of nanoflows?Are there security, performance, or maintainability risks in placing significant business logic inside nanoflows?What is the recommended pattern for separating UI logic from core business logic?Is it considered best practice to centralize business rules inside microflows and use nanoflows mainly as orchestration or UI-layer logic?I am particularly interested in recommendations aligned with Mendix best practices and real-world enterprise project experience.Thank you in advance.

asked 2026-02-26

Gowtham R

3 answers

0

main difference between microflow and nanoflow is where they execute. Microflow run on Mendix runtime and nanoflows run directly in the client

Because microflows run on the server, they are better suited for business logic, integrations, and anything involving sensitive data such as API keys or credentials. microflow execute within transaction. That means if something fails in the middle of the process, the changes can be rolled back.

Nanoflows are more focused on improving the user experience. Since they run on the client, they help reduce unnecessary server calls and make the UI feel faster and more responsive.

By default in nanoflows entity access rule are applied this means when objects are retrieved in a nanoflow, only the ones for which the current user has read access will be returned. Committing an object only succeeds when the current user has write access for all changes.

Nanoflows are also important in offline mobile applications, where logic must run locally on the device without a connection to the Mendix runtime. In such cases, microflows cannot execute, so nanoflows handle the local processing and synchronize later when the app comes back online.

Since nanoflows execute in the browser, any sensitive information such as API keys or credentials should never be handled directly in nanoflows. Even if this information is not displayed in the UI, it can still potentially be exposed through browser developer tools

In general, microflows are best suited for core business logic and transactional processing, while nanoflows are best suited for UI interactions, client-side behavior, and offline scenarios.

You can read more about microflows and nanoflows in the Mendix documentation:

https://docs.mendix.com/refguide/microflows-and-nanoflows/

https://docs.mendix.com/refguide/microflows/

https://docs.mendix.com/refguide/nanoflows/

answered 2026-02-26

Satish M

0

Meanwhile I avoid using Nanoflows. The only advantage is the slightly better speed because it is executed in the browser. But you may encounter security problems as described above and really have to pay attention. I never experienced any delay compared to a Microflow.

answered 2026-02-26

Patrick Uhter

Ahmet Kudu · Accepted Answer · 2026-02-26

In enterprise Mendix apps, keep core business logic in microflows. Use nanoflows mainly for UI responsiveness and client-side orchestration.

Microflows should be used when logic affects data integrity, authorization, auditing, integrations (REST/SOAP), scheduled/background processing, or anything that must be enforced consistently regardless of the client (web/native). They run on the server and are the right place for “source of truth” rules.

Yes, there are risks putting significant business logic in nanoflows: the client is less trustworthy, rules can be harder to govern consistently, and changes may create duplicated logic across pages. Performance can also degrade if a nanoflow triggers many server calls in a chatty way.

Recommended separation pattern: Nanoflow = UI logic + call microflows. Use nanoflows for immediate UX (show/hide, validation hints, offline scenarios, lightweight calculations) and delegate “real” actions to microflows (validate + commit, apply rules, write logs, call integrations).

So yes: best practice is to centralize business rules in microflows, and use nanoflows primarily as an orchestration layer for the UI.

If this resolves the issue, please close the topic.