5 Best Practices To Use Mendix The Right Way

This article covers five best practices every business needs to follow when using Mendix for a user-friendly, secure, scalable, seamless, and highly maintainable application.

Mendix is a rapid application development (RAD) platform that allows you to create digital solutions for mobile, web, and integrations without writing code.  

It is a powerful platform that enables enterprise application development with the user in mind. But with any RAD tool out there, there are certain best practices and things to watch out for when building an application using a particular technology. 

If you find yourself having trouble with Mendix or using it without getting a real ROI, the reason may be related to how you use Mendix. If that’s the case, make these 5 best practices your new best practices.  

Following these five best practices will make sure you’re able to create an application that is user-friendly, secure, scalable, and easy to maintain.  

Below are 5 best practices to use Mendix the “right way.” Let’s dive right in. 

Mendix Best Practice #1: Basic: Do not code in a low code platform 

Whether you are new to the software or a seasoned veteran, it is important to follow good practices in the coding world. When developing in Mendix, the mantra has been to not code in a low code platform.  

But some developers try to follow their previous development approach in a low code platform, which should not be the case. 

1. Mendix is a feature-rich platform. Learn to use it the right way to develop applications. 

For example: Use the grid available, do not try to create tables using the HTML block. 

2. UI Elements should use a built-in data source. Developers are trying to call external API from the JS block available. Instead, developers should use Mendix’s predefined approach for API calls. 

3. Using the Mendix features the right way is directly related to the application’s life as it will help maintain security and support the application’s scalability. 

Check out this video from our software engineer, Kiran Krishnan, who explains the next 5 best practices which we missed adding in this blog for speeding up low code development with the Mendix tool.

Mendix Best Practice #2: Keep in mind the maintainability of the application  

Applications are meant to exist for a long time. Different developers handle projects over the years. And, hence, keeping the environment clean and understandable is mandatory. 

1. Structure the folders appropriately as per the project story so that it is understandable for other developers. For example, common Microflows or Nanoflows should be placed in a folder identifiable to become reusable.

2. Modules within a project should function as separate applications. Domain Models, Microflow, NanoFlow, Styles, etc., can be placed within.

3. Use Annotation as much as possible to explain the functionality achieved—some common places where it’s mandatory are Microflows, Domain Models, NanoFlows, etc.

4. Keep in mind that Mendix is constantly working on making it better. Always stick to the Mendix approach of development to ease the process of upgrading the application.

Mendix Best Practice #3: Domain Models 

A good Database Design is like a strong foundation for an application. Build domain models that are clean and designed for the future of the application.

1. Name the entity and attributes appropriately such that it is descriptive. Keep in mind that Mendix automatically name’s the association between entities.

2. Entities with high interactions should be indexed. Mendix retrieves the object with all columns, and indexing helps get the Mendix ID fast and also helps in sorting.

3. Delete behavior has to be configured effectively. Mismanaged configurations can accumulate orphaned data which can occupy unnecessary space. For example, deleting an object can leave its associated objects useless if delete behavior is not appropriately configured within the domain model.

4. Maintain separate domain models for each module and minimize the association with entities with other modules

5. Be cautious when using calculated attributes. Calculated Attribute gets triggered every time an object is changed or retrieved. In such a case, it will result in an extra load (and delay) while the outcome of the logic is not used. Creating calculated attributes always affects performance, so you should evaluate whether it is necessary to use them.

6. Non-persistent entity is instrumental in avoiding unnecessary associations between entities. Non-persistable objects in Mendix are not kept in the runtime server but maintained in the Mendix client.

IT departments are strapped for time with incredibly high demand for digitization. They are turning to low-code platforms to simplify complex application development and deploy quickly. Check out our webinar to learn why you should adopt a low-code platform now. 

Mendix Best Practice #4: MicroFlow 

Generally, microflow names should include the type of event which triggers them, the name of the main entity being processed, and the operation being performed: {PREFIX}_{Entity}_{Operation}.  

For example: ACT_Vendor_StartWorkflow 

1. Do commits after the loop in a list commit. If needed, create a list named < entity>_CommitList before the loop and collect the items committed there. For retrieves in a loop, consider retrieving all data before the loop and do finds on that list inside the loop. If loops contain decisions, consider if the decision logic can be a query before the loop to minimize iterations.

2. Prevent unnecessary retrieves if objects or lists can be passed as parameters.

3. Use the retrieve over association if possible. This uses caching, which is more readable, and it uses an index. If business logic requires the database value (because the value over association might be changed), understand a database retrieve is needed.

4. Commit as late as possible. A commit locks that record (or list of records). This means any other user/logic that wants to commit the same object must wait until the first transaction is finished.

5. Split microflows up into logical, functional elements. If a microflow has more than twenty-five elements, split it up by creating a sub-microflow for a part of it, for example, by separating presentation logic from business logic.

Mendix Best Practice #5: Security 

It is important to remember that information security is a constant battle. That is why Mendix always ensures its clients’ data safety and security through an effective and reliable data protection strategy combined with an aggressive attack resistance strategy. Follow these best practices for maximum application security. 

1. Specify access rules on an entity applied when a query is executed, restricting the data before returning to the user. 

2. Always use Mendix native components, which eliminates the concern of injection. Queries (like XPath) are parameterized and therefore always escaped, making SQL injection impossible. When using components from the Mendix app store or external interfaces, ensure they are escaped to avoid injection. 

3. Restrict access to request handlers from within the developer portal (Environment details) like disabling unused endpoints, apply IP restrictions or client certificate authentication. 

4. Encrypt sensitive data stored in the database. Encryption modules are available in the Mendix app store that helps encrypt sensitive data. 

5. The username of the administrator can be changed in-app Security settings on the administrator tab. It is advisable to rename the admin user. 

6. Use SSL connection and public key for the endpoint in the application. Also, HTTP headers can add an additional layer of security and help you detect specific attacks. 

7. Remove unused modules, widgets, Java libraries, microflows that are not being used. Keeping your app hygiene at a high level will reduce the chances of a vulnerable application. 

Final Thought  

Undoubtedly, Mendix is an amazing platform that companies use to build prototypes, MVPs, and production-ready applications rapidly.  

The advantages of using Mendix include its extensibility and speed; it can take something like a week to build what could otherwise take months or even years.  

But we all know that with great power comes great responsibility. Zuci Systems is a low-code implementation partner and has successfully deployed 200+ low-code applications. Check out how we helped small, medium, and fortune 500 companies with low code application development.