8.2 Nanoflows Architecture & Client-Side Execution

8.2 Nanoflows Architecture & Client-Side Execution

Exam Focus: Nanoflows are scored under the Microflows and Pages sections rather than as a section of their own, and the questions are almost always comparative. You must know where a nanoflow executes, which modelling activities are valid inside a nanoflow versus a microflow, how a nanoflow invokes a server microflow, and why logic running on the client can never be the only place a rule is enforced.

In traditional web applications, every user interaction that requires logic—such as calculating a dynamic price, validating a field condition, or toggling UI elements—requires sending an HTTP request across the internet to the application server. Under high-latency cellular connections or in disconnected offline environments, this server dependency introduces jarring interface freezes and broken user experiences. To overcome this limitation, Mendix introduced Nanoflows.

---

The Nanoflow Client Execution Engine

A Nanoflow is a visual flow of logic that is modeled identically to a Microflow in Mendix Studio Pro, but executes entirely on the client device.

Where Do Nanoflows Execute?

• In Web and Progressive Web Applications: Nanoflows are compiled into optimized ECMAScript (JavaScript) bundles and execute on the web browser's JavaScript engine (such as Google Chrome's V8, Mozilla Firefox's SpiderMonkey, or Apple Safari's JavaScriptCore).
• In Native Mobile Applications: Nanoflows execute inside the React Native embedded JavaScript runtime (such as Hermes or JavaScriptCore) running locally on the iOS or Android hardware.

[User Tap / UI Event]
       │
       ▼
[Client Device JavaScript Engine] (Hermes / V8)
       │── 0ms Network Latency
       ├── Executes Nanoflow Activities Locally
       ├── Reads / Writes Local State & SQLite DB
       ▼
[Instant UI Update / Re-render]

The Zero-Latency Paradigm

Because nanoflow logic runs directly on the local CPU of the smartphone, tablet, or browser, it introduces zero network latency (0 ms). Calculations, conditional visibility updates, page transitions, and local data modifications execute instantaneously. This makes nanoflows the ideal architectural choice for:

• Dynamic form calculations (e.g., calculating an invoice line total as quantities change).
• Instant field validation with immediate user visual feedback.
• Offline business logic execution in remote locations.
• Device hardware orchestration (accessing the camera, GPS, or accelerometer via JavaScript actions).

---

Available Activities & Logic Capabilities in Nanoflows

While nanoflows share a visual modeling language with microflows, their activities are tailored specifically for client-side operations:

1. Object & Data Operations

• Create Object: Instantiates a new entity in client memory. In an offline-first native app, this object is immediately staged in the local SQLite database.
• Change Object: Mutates attribute values or associations of an in-memory object. Can trigger immediate client-side UI re-rendering.
• Delete Object: Marks an object for deletion. Offline, it flags the record in local SQLite as deleted so it can be purged from the server upon synchronization.
• Retrieve: Nanoflows can retrieve objects from memory (context variables or associations) or from storage (the local SQLite database in an offline native application). Note: Nanoflows cannot execute direct database queries against the central server database.

2. UI & Navigation Interactions

• Show Message: Renders a native alert dialog or toast notification (Information, Warning, or Error) directly to the user.
• Open Page: Navigates to another page within the current navigation profile, passing context objects instantly without a server round-trip.
• Close Page: Closes the active page or modal popup dialog.
• Validation Feedback: Attaches a visual validation error message directly below a specific widget or input field on the active page, prompting the user for correction.

3. Client Extensibility: JavaScript Actions

Just as microflows can be extended using custom server-side Java Actions (javasource/), nanoflows can be extended using custom JavaScript Actions (javascriptsource/):

• Developers author JavaScript using modern ECMAScript standards (including async/await and Promises).
• JavaScript actions can interact with the DOM in web apps or import React Native community libraries (such as Bluetooth, NFC, or biometric authentication modules) in Native Mobile apps.
• JavaScript actions return primitive values, entities, or lists directly back to the calling nanoflow.

4. Server Integration: Calling Microflows

Nanoflows act as the bridge between client devices and the central Mendix Server by utilizing the Call Microflow activity. Studio Pro provides two distinct execution modes:

Nanoflows vs. Microflows: The Deep Architectural Comparison

To pass the intermediate certification, you must understand where the technical boundaries lie between Nanoflows and Microflows.

---

Client-Side Security Architecture: Zero Client Trust

A critical responsibility of intermediate developers is safeguarding enterprise data integrity when utilizing client-side logic. You must adhere to the foundational security principle: "Never Trust the Client."

1. Source Code Exposure in Client Bundles

Every nanoflow, JavaScript action, and client-side validation modeled in Studio Pro is compiled into JavaScript and shipped to the client device:

• In web applications, any end-user can open Chrome Developer Tools, view the loaded .js bundles, set breakpoints in nanoflow steps, and inspect in-memory variables.
• In native mobile apps, malicious actors can decompile the .apk or .ipa archive, inspect bundled JavaScript code, and analyze API endpoints.
• Architectural Rule: Never store sensitive secrets, unencrypted API private keys, master encryption tokens, or proprietary business calculation algorithms inside a Nanoflow or JavaScript Action.

2. Entity Access Rules Enforcement

In server-side Microflows, developers can uncheck the Apply entity access property, allowing the microflow to execute with elevated administrative privileges (for example, generating internal invoice numbers or updating audit tables that regular end-users cannot view).

Exam Trap: Nanoflows CANNOT bypass Entity Access. In a Nanoflow, entity access rules configured in the Domain Model are always strictly enforced based on the logged-in user's assigned User Roles. If a user does not have Read access to an attribute, a Nanoflow cannot read it. If a user lacks Write access to an entity, a Nanoflow cannot create or modify it.

3. Server-Side Re-validation Requirement

Because client-side nanoflows can be manipulated or bypassed by an attacker intercepting network calls (e.g., using Postman or Burp Suite to send altered HTTP payloads directly to published microflows):

• Nanoflows should be used for user experience (UX) validation—providing rapid, friendly feedback to honest users.
• Microflows must be used for security and integrity validation—re-verifying all business rules, calculations, and permissions on the server before committing changes to the central database.

---

Nanoflow Exam Traps & Practical Scenarios

Scenario 1: Attempting to Call Java Actions from Nanoflows

A developer wants to parse an Excel spreadsheet using a Java library inside an offline mobile app and tries to invoke a Java Action from a Nanoflow.

• The Reality: Nanoflows execute in a JavaScript environment where the Java Virtual Machine does not exist. Studio Pro will disallow dragging a Java Action into a Nanoflow. The developer must either use a client-side JavaScript action or call a Microflow that runs the Java action on the server.

Scenario 2: Synchronous Microflow Calls While Offline

A field inspection app triggers a nanoflow containing a synchronous Call Microflow activity while the inspector is in a remote underground facility.

• The Failure: The synchronous call attempts to open an HTTPS socket to the Mendix Server. Because there is no network connectivity, the call immediately throws a network exception, halting the nanoflow and displaying an error dialog to the user.
• Best Practice: Always inspect network status using a JavaScript action or connectivity check before invoking server microflows, or defer server transactions to the formal offline Synchronize activity.

Scenario 3: Transaction Rollbacks in Nanoflows

A developer expects that an error in a Nanoflow will automatically roll back changes made to database records.

• The Reality: Nanoflows do not manage database transactions. If a nanoflow changes three objects in client memory or local SQLite and encounters an unhandled error on the fourth activity, the first three mutations remain in local storage. Automatic ACID transaction rollback is exclusively a feature of server-side Microflows.