Hi guys,
Seen the nano flows are faster in some cases I would prefer to use them over micro flows. But since we are used to microflows and the nano flows have (changing) limited possibilities, we have to know each time what the current possibilities are before choosing to develop in a micro flow or nano flow.
Is it not an idea to begin always with a micro flow development, whereby the modeler checks automatically whether the same micro flow could be handled with a nano flow. And if so, the modeler could generate the same logic in a nano flow (as replace).
A general function to check all micro flows with nano flows replaceability would be also really nice to have.
It sounds may lazy, but I think it could be as helpful as generating entity pages automatically.
EDIT 1: I agree with Rom that there could be unwanted cases to consider. But I think that the dev is at the end responsible for the flow and the applicability of it in nano flow. Furthermore I believe that the use cases are far more (offline, ui, navigation, even some validation cases, did not mention the future applicability with native mobile apps using react native as javascript probably also in nano flows) than the unwanted . And I think with some warnings/general education (citizen) dev's could know better when to use/avoid certain use cases.
BTW, I am not sure...but I thought to hear this functionality already in Johan's speech at MxWorld.
Hey, nice suggestion! Converting microflows to nanoflows can be very beneficial on certain cases. I’d like to add some more aspects to consider:
- Converting a microflow to a nanoflow which contains several database related activities (retrieve, commit, rollback etc) might be slower than microflow – each activity makes a separate request to server for an online app.
- An exception to above – converting a microflow which requires a large client-state (hundreds of objects) to be sent to server might be beneficial, even if it contains several database related activities. You can read about client state here.
- Microflows run in the system context by default. Nanoflows always run in the user context. Behavior of the activities might change when a microflow is converted to a nanoflow. For example – a “Retrieve activity” would only retrieve the objects user can access in a nanoflow whereas it would retrieve all matching objects in a microflow.
- One of the differences between microflows and nanoflows is that result of the each step in a nanoflow is immediately reflected in the UI since it runs on the client. Imagine changing and committing 3 objects of the same type with “Refresh in client” set to yes in a microflow. Converting such a microflow to a nanoflow could cause 3 times more refreshes on the UI.
Such behavioral changes must be taken into account before suggesting converting a microflow to a nanoflow.
This would be horrible: Mendix would suggest validation flows (which contain simple checks and validation messages) to be executed as nanoflows. Citizen developers would click ‘convert to nanoflow’ and now all validation is client-side, i.e. there is no validation.
Yes, great Idea, but only make it suggest a nanoflow if all the functionality used in the microflow is available in the nanoflow.
This would be amazing and very useful for Mendix newbies. :)