The “Optimize performance” section in the appfarm documentasion briefly mentions that “Splitting into smaller apps will reduce the overall complexity of the solution, spread the load better, and increase the performance for end users.”
What are the concrete benefits of doing this? Is it also benefitial to split an app in to one main app and several sccondary apps, where the secondary apps are Iframed into the main app? Are there both client side and server side benefits in doing so?
Hi!
In a perfect world, where an App was created with strict “on-demand read” of a limited amount of data (runtime only data sources), with limited use of function properties on data sources, and moderate view sizes, an App can be pretty large. In this case, the App Size itself (typically 0.1 to 15 MB) + the initial data (e.g. 3 MB) is what is read on app load, and the bandwidth for the user must be able to load that within a reasonable time. Splitting this into smaller apps, may cause the loading time to be e.g. 1/3 of this, which percentage-wise is significant, but not notable for the user.
But the world is not that perfect. Having an increasing app size normally implies an increased number of data sources - causing the initial data size to increase. It is mainly the app data - both the number of records and columns, and the dependencies between them - that affects performance as the app grows. And if the views become huge and a lot of them, it also affects the loading time a bit.
Also, an app “covering everything” may be a nightmare to maintain, as there may be so many dependencies, and often also conditionality on functionality and UI based on roles.
Splitting into multiple apps is rather a strategy to have from the beginning. It is not always easy to pinpoint when it makes sense, but for example: You could create a “backoffice app” for handling everything in your organization - from HR and staffing, to business operation and CRM. This app could be split into three: Staffing, Operations and CRM - also allowing for easier role access control, and each will also be easier to maintain and faster than the “one large app”. Core UI structures may be set up in a separate app and reused using Shareable UI Components.
Regarding the “moderate view size”: is there any performance difference when using visibility groups (for example, controlled by a menu) between keeping all app sections within a single view versus splitting them into separate views and using view containers?
Hi!
The runtime behaviour in the App should be the same. Non-visible containers (e.g. when using visibility groups) are not mounted and should not consume any memory. So it should be more or less the same, these two approaches!