In our last blog post we focused on the low-code side of the story, explaining how the Mendix workflow doesn’t require a traditional application development project set-up. How Mendix offers no-code and low-code solutions to building in-depth development capabilities through front- and backend code extensions. Today we’ll take a closer look at the use of extensions within the Mendix framework. Quick heads up - it’s going to get technical! Let’s begin.

Interpretation before code generation

Mendix is a model-driven development platform. That means it uses pre-defined visual components to build applications. With other low-code platforms, a model generates the necessary code to deploy the application. But Mendix likes to stay away from code generation. Instead, to run the application, Mendix interprets the model during runtime. Mendix runtime has the logic to translate microflows, nanoflows, screens and all other components into a working application. Each Mendix application can be deployed in various ways, for example to the Mendix cloud, SAP Business Technology Platform, IBM Cloud, Container technologies (Docker Images, Kubernetes), Azure or any (on-premise) environment you configured yourself.

All that to say Mendix chooses model interpretation over code generation. What does that mean? Simple - extensions are fair game! Using code generation would mean you could only add extensions within the generated code of one specific application, creating a discrepancy between the model and the generated code. But since Mendix uses model interpretation, every extension is seen as an extension of the model, not of the code. Whenever the extended model is interpreted by Mendix runtime, the extension is automatically part of the exercise.

Why use extensions?

Mendix can solve quite a lot using its built-in features, but it can’t cover everything. Using extensions offers an easy solution to specific front-end and UI needs, for example allowing the implementation of Javascript components (React) into Mendix. Extensions can also be used to build completely new UI components, to build reusable integrations with external systems, to implement external Java libraries or to improve productivity and quality throughout the build and deploy process.

Mendix offers solid ground for the development and use of extensions within its architecture. On top of that developers have access to a wide range of APIs. The first flavour of APIs can be used throughout the development of simple extensions, allowing the developer to use Mendix Studio Pro functionalities in the domain model, but also in Java and Javascript code, such as microflows. This way, a simple Javascript or Java action can be integrated seamlessly into the application’s existing microflows or nanoflows. The second flavour of APIs run on top of the Mendix architecture and offer support for the building and deploying of an application, even for continuous integration. These APIs can be used to set up projects, work on sprints and stories, collect user feedback and more. The bottom line is that the APIs offer developers complete freedom. For example, you can integrate with Jira or Confluence, or with a dashboard that monitors several applications and environments.

Package and reuse

As developers extend Mendix based on APIs, they want to package their solutions. Perhaps to reuse them later on, or to share them in a private or public app store. Packaging and using Mendix extensions depends on the component and the technology involved. Solutions include Java actions, pluggable actions, Java connectors, pluggable widgets, modules etc.

Mendix widgets, connectors and modules (among other bits and pieces) are future-proof. The Mendix app store indicates which Mendix Studio Pro version is needed to run particular apps, so you might need to check if a widget still works after a new Studio Pro update. But even then, since Mendix’s approach is based on model interpretation and not on code generation, it doesn’t mean you need to go through endless lines of code. That in itself also offers protection against lock-in as well. Should a company ever decide to leave the Mendix platform, they’re not just left with a (complex) code dump, but with a meaningful model.

Would you like to learn more about the extension-abilities of Mendix? Make sure you check these pages on the Mendix website:

Read more!