How to avoid common pitfalls in low-code development
Building applications using low-code brings speed, flexibility and agility to the development process. Developers can learn to use a low-code platform like Mendix within months instead of years and is therefore more accessible. If used correctly, low-code platforms offer a very powerful way to, in popular terms, “bridge the gap between business and IT”.
In my 12 years of experience with low-code development, I have seen the power of it many times. However, I have also experienced the downside: also ’crappy’ apps are easily built with the Mendix software platform. Apps look nice, seem to work and meet customers’ demands at first, but are not sustainable in the long term. Focusing on maintainability, security and performance is crucial for success and can make or break an application.
Every developer is able to build functionality, but creating enterprise worthy applications is a different discipline. Extensive knowledge of the platform is required to make stable applications. In our partnership with Motopp, we have the chance to help a large number of new developers with the start of their Mendix career. We use our experience to provide a deep understanding of the platform. The focus on maintainability, security and performance will help them in building sustainable applications for customers.
In this blog I would like to talk about these three points specifically. Besides creating the functionality the business wants, these should be top of mind for a good developer.
Even though Mendix is very well suited for prototyping and creating proof of concepts fast, a lot of the applications that I have seen were actually used for years. Meaning that over time, new features were added and maintenance had to take place. Therefore, in order to benefit from the low-code possibilities of the Mendix platform, you have to create a maintainable application. Maintainability means being secure, neat, organized and well structured. Plus you need to think about building reusable components, so that you’re not developing the same things twice and/or differently. Sounds fun, right?
Well… Not for most developers. That’s why less attention goes to the maintainability aspect.
So, what should you do?
Best practices and conventions can help you a long way. Mendix has a list of best practices which helps you to structure your application. Furthermore, being aware of the importance of maintainability will help you to design and build a future-proof app. Like I mentioned before, reusability is a key-aspect too: by focusing on creating snippets or sub-microflows you can develop reusable code. A nice example of a pattern for this is a ‘Get or create’ flow that you can reuse to either create an object if not existing or retrieve it if it’s already created.
Even though Mendix enforces security within the platform and checks for consistency in a large part of the application, it is still necessary to check for yourself whether your application is secure and where potential security problems might be. For example, if not set correctly, working with anonymous users potentially opens a free portal to your data. Or what about using widgets, like an HTML editor, that potentially gives a user the power to execute malicious code?
The basics of security are well defined and documented in this piece of Mendix documentation. We believe that the best way to develop a secure application is to start from the point of providing no access at all for a user. From there, you enable access piece by piece and only give access to things that are absolutely necessary. For example regarding access on an entity, don’t give read/write access on all attributes just because it is easy. Only give access to what is needed.
Besides the basics, Mendix has a pretty neat document with security best practices which gives you some ideas where to look. And remember: security is crucial.
A good performing application is key for success (and adoption!) of the app. Performance however, can be very subjective and optimizing code prematurely could be costly without having a valid reason to do so. Therefore, ask questions about performance in the design phase: what kind of data will your piece of functionality need to process and does the user have to wait for it? Furthermore, if you are optimizing something that is being defined as slow, don’t analyze or optimize on a gut feeling. Instead, use measurements and quantify.
Besides this advised way of thinking, Mendix also helps you out in their documentation with some best practices and patterns that helps your app to perform better. You’ll find some practical tools to make specific actions faster or less prone to slow functioning.
Wrapping it up
I have seen what happens when you don’t have a keen eye on maintainability, security and performance. Due to time pressure, inexperience or over-focus on functionality, apps are being developed that work fine in the beginning. However, when the app needs adjustments, handles bigger volumes or gets exposed more, it becomes all too clear that cheap (or fast) equals expensive in the long term.
Focusing on the pillars maintainability, security and performance provides guidance to develop high quality and future-proof applications. At Squad Apps, we have a high standard when it comes to the quality of applications. With every application that we develop we make sure it meets all the criteria relating to maintainability, security and performance. Now and in the future.