Welcome to read "Mendix Architecture System Overview (1)" and "Mendix Architecture System Overview (2)" , this chapter will explain Mendix's Runtime architecture and 12-Factor architecture.
Runtime Architecture
What is Mendix Runtime? How does it support key architectural principles?
Mendix Runtime executes your application in the context of cloud native architecture. In this section, we will introduce the core components and related functions of Mendix Runtime, and we will also delve into several important aspects of Runtime execution.
01. Which component is responsible for the execution of the model?
Mendix Runtime interprets and executes the application model. Runtime adopts industry-leading 12-Factor App compatible design of Java and Scala technology.
02. How does Mendix execute the model?
Mendix executes the model directly at runtime, which means that the model is an application, not an intermediary. Unlike the method of visual modeling and design that actually generates code (such as Java or .NET), the Mendix model interpretation method has many unique features and advantages, as described below.
1. Change Management
Can more easily adapt to application changes. In addition, since the model is an application, Mendix guarantees the compatibility of the application and the model.
2. Custom extension
The custom code extension model is to customize the code and include it in the consistency check, instead of inserting the custom code into the generated code, so it is more elegant. Mendix's model interpretation method solves the basic round-trip problem of code generation, that is, changes in the model will conflict with the extension of custom code. In addition, there are no custom changes in the generated code, that is, the technical architecture of the platform can be modernized without affecting the model, which means that it is easier to benefit from technological innovation and at a lower cost.
3. Monitoring
Compared with pre-defined detection parameters, the monitoring and analysis of application behavior in Runtime can be set more dynamically and flexibly.
4. Debugging
Developers do not need to understand the relationship between the generated code and the visual model, and can debug and solve the problem on the model, without operating on the generated code, so it becomes easier for the developer to debug and solve the problem.
03. How does Mendix implement a stateless architecture?
In order to ensure scalability, performance and high availability, Mendix implements a stateless Runtime; this means that no matter whether it is a previous request or a subsequent request, any available Runtime instance can handle user requests. To achieve this, the Runtime instance has state during the user's request. At the end of the request, all submitted states will be saved to the database; all unsubmitted states will be returned to the client together with other data required by the client.
What are the components of Mendix Runtime?
Runtime consists of two main components:
-
Client- web and mobile client
-
Runtime server -Scalable Runtime that handles server-side logic
01. Server architecture
The Mendix server architecture consists of multiple components for executing logic, managing data, client communication, and implementing security. The following diagram outlines all components and briefly explains their responsibilities:
Mendix Runtime consists of the following components:
-
Platform core -responsible for the startup and shutdown of the application, and load the required libraries and extensions
-
Object cache -handles the creation and deletion of objects
-
Session manager -manage the creation of user sessions, clean up logged out or abandoned sessions
-
HTTP server -In Mendix Runtime, it is used to process requests from web and mobile clients and service requests
-
Microflow engine – perform microflow and microflow
-
Data layer -persistent storage and retrieval of objects from the application database; and responsible for creating and updating the database structure required to save the data: the data layer supports a large number of different databases, and stores data by using common data model design best practices
-
Integration layer – handles incoming and outgoing service requests for web services, REST APIs, application services and OData
-
Client API -responsible for communication with web and mobile clients; this API is used to retrieve data, keep data changes and execute micro-flow logic
-
Configuration API -Developer Portal and container buildpack use this JSON API to configure Runtime
-
Monitoring API -Developer Portal and container buildpack use this JSON API to retrieve monitoring metrics
-
Custom APIs -This Java API is used to extend Mendix Runtime (for example, for micro-flow activities or entity listeners)
02. Client Architecture
Mendix Client is composed of UI component layer, logic layer that executes offline logic, and data layer that is stored offline, and is responsible for user interaction.
Mendix Client consists of the following components:
-
Communications layer ——Use secure JSON over HTTP protocol to exchange metadata, session management and data with Mendix Runtime server
-
Data layer —— Manage the data used by the front end; process the state based on the React-Flux model and push the changes to the UI components
-
Logic layer -Use Mendix nanoflows to handle data validation and more complex logic
-
UI component layer -manages the life cycle of components and the communication between components, and provides out-of-the-box components
1. Mobile client
Mobile applications use the same HTML5-, CSS-, and React-based client-side architecture, but they use Apache Cordova for deployment. This framework enables mobile applications built using the most advanced web technologies to provide an excellent mobile user experience:
-
Accessibility -The application can be found in the standard device application store, installed on the mobile device, and opened via the icon.
-
Offline availability -Since the application is installed on the mobile device (including all necessary resources and possible cached data), the end user can use the Mendix application offline, and the related application data is cached in the SQLite database on the device.
-
Support for native functionality – JavaScript applications use native device functionality through Apache Cordova, allowing you to benefit from all the sensors in your mobile device, such as cameras and microphones.
2. Web Client
The web client uses a single page architecture, where a single JavaScript web page is loaded into the browser, and then the browser will update the page and interact with Mendix Runtime according to the requirements of the user's operation. This may include the retrieval of some web pages and the retrieval and storage of data.
The client is mainly implemented using HTML5, CSS with Sass and Bootstrap, and React framework.
12-Factor Architecture
What is the 12-Factor App application method?
Although not a strict set of architectural principles, the 12-Factor App approach is a set of best practices for cloud-native applications.
How does Mendix Runtime support 12-Factor cloud native applications?
The following describes how Mendix follows the requirements of the 12-Factor App method.
01. Code Library
By default, the source code of every application built with Mendix is stored in the code repository of Mendix Team Server. When deploying an application, a package will be created based on the model stored in Team Server and deployed to different environments, such as acceptance or production.
02. Dependence
All dependencies (such as modules and libraries) used by application modules are part of it, which means that there are no implicit dependencies on tools in the environment, ensuring the reliability of deployment.
03. Configuration
Configuration requirements are defined in the application model through constants, and you can specify these values during deployment in the environment, or through APIs called in the CI/CD pipeline. Because the actual configuration values are not part of the model, the same deployment package can be deployed in any environment without changing the application model.
04. Support Service
All external requirements (such as a database that stores application data) and services called from the application can be configured at deployment time. As with the previous requirements, this ensures that the same tested deployment package can be used under all conditions, with support services, and no model changes are required.
05. Build, release, and run
If the code can be modified in a production environment, then the extension of the application will become unpredictable and unreliable, making debugging and problem-solving more difficult. In order to avoid this problem, the Mendix platform clearly separates the build and run phases.
In the Mendix Developer Portal, you first need to build a data package in the model, and then deploy it to your environment. If you want to change the code in the product, you need to modify your model and then build a new data package. Mendix also provides APIs for building and deploying applications, so you can incorporate this method into a custom CI/CD pipeline.
06. Process
Mendix is completely stateless at runtime, sharing data through the database to ensure the feasibility of expansion and recovery.
07 . Port Binding
In order to simplify the expansion and operation of the same application in different environments, the application should be self-contained (that is, it is configured to receive client requests). The Mendix application is configured in this way, enabling the underlying platform as a service (PaaS)-for example, Cloud foundry-to easily expand the number of containers of its hosted applications.
08 . Concurrent
Mendix uses a combination of Java threads and processes to extend the needs of end users. The 12-Factor App method emphasizes the necessity of expansion through the process; otherwise, your expansion needs will be limited to the maximum range that a Java Virtual Machine (JVM) can support (vertical expansion). Through the expansion of the process, you can easily add additional resources (horizontal expansion).
09. Disposability
Mendix Runtime instances can be stopped and started as needed. In a multi-instance environment, it is usually difficult for users to detect whether the Runtime instance has restarted; this makes horizontal expansion easier and faster, and the deployment of new versions or new configurations will be faster.
10. Development and production insured price
To ensure quality, the behavior of the application deployed in the test environment should be consistent with the behavior in the production environment. In Mendix Cloud, all environments are the same, the only difference is configuration, data and applications. Data can be moved between environments through backup and recovery, thus ensuring the testing of representative data.
11 . Log
Mendix Cloud uses Cloud Foundry firehose to collect log events of all applications, and can be viewed and filtered in the Mendix Developer Portal.
12 . Process Management
In order to avoid synchronization problems, the 12-Factor App method recommends transferring the management code together with the application code. Mendix took this approach, so the only code that runs in the application environment is the code that is part of the application. In other words, you need to manage the code as part of the model. Users usually implement this function through management logic in the management page: execute microflows after the application is started, or create APIs to trigger management operations.
For more information, please visit the following link:
Mendix official website: https://www.mendix.com/zh/
Mendix industry solutions: https://solutions.mendix.com/
Mendix platform guide: https://www.mendix.com/evaluation-guide/
Mendix animation display: https://www.mendix.com/demos/