Application developers are under constant pressure to build their product and get it out the door so they can start building the next one. Taking the time to put the final polish on an app can be a luxury they’re not afforded, no matter how much the developer wants to make sure all their I’s are dotted and their T’s crossed.
Dotting I’s and crossing T’s is healthy for the bottom line. Sure, an explorer folder structure that is logical and well maintained might not have the “wow” factor of a flashy new function or a snazzy UI. But a well-built app brings with it benefits that more than pay off the investment of extra time spent:
- It minimizes technical debt
- It makes the app easier to maintain
- It makes it easier to onboard developers to the project
To help you get the most polish with the minimum amount of spit, I’ve put together some examples of areas of consideration, outside of the application business functionality requirements, for building a cleaner and maintainable application on Mendix.
Security, Security, Security
Consideration for security should always be at the forefront of your mind throughout development and testing. However, I encourage you to regularly review the overall security implementation to ensure you maintain the principle of least privilege. This especially is important since you would typically have multiple developers, with varying levels of Mendix development experience, working on the same application and at the same times.
Maintain entity-level security
Ensure you review the CRUD rights on the entities and attributes. Where it makes sense, apply Xpath constraints to further restrict the CRUD access rights for the entity. For example, only allow read access to the attributes if account object = belongs to me.
Another consideration is to set the ‘Default Attribute Rights for New Members’ to ’None.’ It is a good practice for developers to think about the read/write access rights of each attribute instead of automatically setting it and leaving it as an afterthought.
Blank out default values for sensitive constants
Empty out all default values of constants (environment variables) for sensitive data (e.g. API keys). Do not store sensitive information as default values of constants.
Rename default ‘MxAdmin’ administrator user
I recommend renaming or customizing the default administrator user.
Modelling
Address modeler warnings
Where it makes sense, implement recommendations in the ‘Warnings’ tab for custom-created modules.
Review application logs & identify improvement opportunities
Application logs contain a wealth of information that can help you identify symptoms of modelling errors. In the example below, the warning messages tell of autocommit behaviour happening in the application that should be explicitly committed instead.
Listen to the MxAssist Best Practice Bot
The MxAssist Best Practice Bot learns common anti-patterns from a statistical analysis of thousands of anonymized Mendix apps. It also incorporates Mendix best practices for developing microflows, domain models, pages, security, and so on. Review the bot’s recommendations and, where it makes sense, implement them.
Housekeeping
Keep the domain model easy to read
Take a look at the examples below. The data model on the right would be easier to understand for a new developer onboarding onto the project.
Use colors for more readable microflows
By applying default colors to selected microflow/nanoflow actions, you can greatly improve readability.
With a quick glance at the screenshot above, you can easily identify a sub-microflow call (green) and logging actions (grey) within the microflow logic.
Clean-up unused items
Clean-up or mark as “unused” the unused items in your custom-created application modules. If you want to keep the unused or excluded items as references while keeping the Project/App Explore clean, put them in an ‘Unused’ folder.
Update your Marketplace modules and Mendix Studio Pro
Identify opportunities to update your Marketplace modules and your version of Mendix Studio. This will ensure you’re enjoying the highest level of security and stability, and it will minimize the impact of the next required upgrade.
Conclusion
Remember, maintaining a clean, organised, and optimized application each time you deploy to production will keep the application engine ‘well-oiled’ and primed for the next iteration. It will make it easier if you incorporate the recommendations I’ve shared as part of your business-as-usual development cycles rather than as a big one-off exercise at the end of a product iteration.
The points covered in this blog are not in any way a comprehensive list for polishing up your application before a production deployment. You can find even more helpful suggestions in these articles: