I just want to start a discussion or get an insight on my mobile application architecture.
We have designed our App such a way that ,single End-User Module. which contains only the screen reference to different web blocks in different Domain Outsystem Applications.
Currently we have nearly 16O screens which are reference from web blocks of multiple modules .
There are lots of functionalities are in pipe line to implement ,and am expecting another 50 more screens to be created in near future to accommodate the new business flow.
Currently the Size of my End user module is 3 mB . Is there any size limit or standard of oml size ?
Also am worried about the slowness of the module for opening and Publishing as the performance degrades when the size /reference increases.
Any alternative ? like multiple end user module like Web application ?
Reference https://success.outsystems.com/Documentation/Best_Practices/Architecture/Building_mobile_apps_with_multiple_independent_teams/Mobile_architecture_best_practices
Hi Sabeeb,
The module you are describing seems fairly large, and this page mentions module size as being a possible indicator of poor architecture:
"A module with a size larger than 4 MB could indicate poor architecture (see How to reduce the size of my eSpace)."
I think that module size just by itself isn't immediately bad, but it definitely forces you to check if you're following best practices all around or if there is something you should be doing to lighten the load of that module. For example, since you are talking about a Mobile application, there is currently no way for you to spread end-user screens across different modules (as that is -currently- a technical limitation from my understanding); but you could double check to ensure that the contents (blocks) and logic of those screens are distributed across several Mobile Core Widgets (_MCW) modules according to some form of more specific categorization. You can do something similar for other contents of your application, e.g. a module for Local Entities, a module for Syncing logic, etc.
Finally, consider if it makes sense to possibly split your large application into smaller apps. If it has 160 screens (and you expect it to grow to 210 sometime soon), which sounds like an enormous number, ask yourself some questions: do all users need access to all of the screens? Or would it make sense to perhaps build more "specialized" applications for each role/type of user (or some subsets of them)? Are you mixing owners/sponsors? This is also very important because it goes beyond keeping your modules small, it could provide some key findings to build a better UI/UX for your users, a smoother application lifecycle and potentially even more straightforward development (e.g. not having to implement countless rules to redirect users, show/hide information or apply different business logic depending on user types).
If you already follow those guidelines strictly, then I am not sure if you can do much more at the moment. At some point with a future update, the platform will allow you to use different end-user modules for the same mobile application. As far as other technical problems go, I have come across this forum post, but something similar may or may not apply to your case as it is based on a Solution Package (.osp file) rather than a single module, and the size is significantly larger over there (~200MB) .