In a recent blog, Mendix Chief Evangelist Nick Ford explored how low-code platforms allow software engineers to focus on what they do best: writing code. In this blog, I want to explore in more depth some of the features of the Mendix platform that help support what software engineers do best.
There are three key areas of the Mendix platform where Software Engineers can utilize their skills to provide a better development experience for others involved in the application lifecycle.
- Model Extensions
- Model SDK
- Platform APIs.
Each is designed to help engineers extend the platform to suit their organization’s needs. Let’s look at each of these to see how they can be leveraged inside the Mendix Platform.
During my time with Mendix, there is one question that I am consistently asked: “Where can I see the generated code?”. My answer is always “There is no code! The runtime interprets the model and produces your application. But, this doesn’t mean you can’t use code to extend your model”.
Model-driven development isn’t a new concept, it’s been around for many years. However, many development tools of the past were either too restrictive or difficult to customize. When customization was available it often required changing the generated code to meet the customer needs. But once you do so you break the model, thus reducing your development speed and making maintenance a nightmare.
Mendix takes a different approach to extensions. Instead of extending your application with custom code, we extend the modeler itself. By extending the modeler capabilities, you can always ensure that your model and your custom code extensions work effectively. You also ensure that any code written is reusable across other applications.
Connectors are a great way to extend the modelers functionality. Connectors are self-contained wrappers which extend the native microflow functionality. A connector, when called by a microflow, will execute a piece of java code, which can be edited in your favorite IDE. The connector can utilize all the functionality in the model including entities, data sets, microflows, pages, and configurations via the Mendix Runtime API. When building a connector, you can choose to add an icon and description, which makes it natively available in the Mendix toolbox. The user of the connector only needs to pass the required parameter to the code, they do not have to understand the underlying Java code.
What makes connectors so powerful is their rich set of parameters and return types. When building any integration, you want to make it as easy as possible to use and make it as generic as possible. By making your connector generic, it ensures it’s easier to reuse in different situations such as passing different data for different use cases.
For example, a connector can have many parameters, which can be both generic, typed or static. Connector parameters currently support Strings, Booleans, Integers, Decimals, Object, List, as well as Any Object and Any List. Once you have defined your parameters and return types the Mendix platform will generate a code wrapper, within which you can define your own custom code. The code can be edited inside your favorite IDE, such as Eclipse, IteliJ and many others. Inside the connector code, you add your own custom code to call out to any Java or Scala library required. These libraries are placed in the userlib folder of your project allowing you to utilize them.
This three-minute video sums up nicely how to build a connector:
The base structure that is needed for every widget will contain 3 essential files:
- xml file – used to describe the folder structure of your widget.
- xml file – used to describe the parameters that can be passed to the widget.
- js file – used to determine the logic of your widget.
Within the widget xml you define as many parameters as you require to pass to your custom code. The parameters have different types depending on the data required, such as strings, Booleans, attributes, objects etc. You may also define which of these parameters are required for your custom code. By setting up the widget this way ensures that it is reliable, self-contained and reusable. For example, two different developers might want to use the same widget but want to pass data from different entities. By using the entity and attribute parameters the users of the widget can use the data they require.
Within the widget JS file, you can define any additional libraries that you want to import into your widget to use.
We have explored how we can extend our models using widgets and connectors, but how about accessing information about the models itself or changing the models programmatically? The Mendix Model SDK is a powerful typescript development kit built on top of the Model SDK, which gives developers programmatic access to the meta-model information.
The Model SDK has four main use cases:
- Import applications from legacy code bases into Mendix
- Analyse application models for static analysis
- Make bulk changes to your application
- Export your models to another code base or platform
By leveraging the Model SDK developers can build supporting tools around the Mendix platform to extend its capabilities. One example is the AQM tool which utilizes the Model SDK to perform software quality analysis. Giving you a five-star rating, based on industry standards, as to how well built your application is. There are endless possibilities with the Model SDK, but if you want to get started then check out the getting started documentation and the API Docs.
We have also put this video together to give you an introduction into the model SDK and the benefits it provides:
The Mendix platform comes with an extensive range of APIs to help developers integrate the platform into their existing DevOps pipeline. By using tools like Visual Studio Team Services (VSTS) or Jenkins deployment pipelines can leverage the APIs to build, test and deploy applications automatically based on a trigger like a commit. These applications can be deployed into any public cloud, on-premise or private cloud offering using either docker or cloud foundry container and run on any container platform like Kubernetes or Cloud Foundry. Developers can combine any number of APIs available from the Mendix product to create your own personalized pipeline. The video below demonstrates how the Teamserver API, Build API, Docker Buildpack, and the ATS CICD API are used to deploy an application live into a Kubernetes cluster based on a single commit.
The Key thing I want you to take away from this blog post is that just because it is low-code development doesn’t mean there isn’t a need or a way to create code. There is always that edge case that requires some level of customization and when you need it the Mendix platform supports it. If you don’t believe us, try it out for yourself!
Now what will you build?