Vision App Maker has an enterprise, cloud-ready architecture based on microservices, where each component has a defined role. The components can run as decoupled services in containers, in a public or private cloud.
Logical architecture
The platform is split into three tiers:
- Client (front end): internal and external portals, the info kiosk application and the mobile app. This tier handles only the user interface and UI logic, and calls the APIs provided by the API Gateway.
- API Gateway: the intermediary between clients and backend services. It exposes the public APIs used by clients and the internal APIs used for content management.
- Services (backend): microservices or monolithic services that implement business logic. They access databases, process data, handle events and communicate synchronously or asynchronously.
Layers
The architecture diagrams group the components into five layers.
| Layer | Components | Technology |
|---|---|---|
| UI layer | Internal and external portals (1…N), info kiosks (1…N), mobile app, browser | React; React Native for the mobile app |
| API gateway layer | Ingress or reverse proxy; App Maker Gateway | .NET Core |
| Microservices / distributed components | App Maker Engine and additional components (1…N); an IoT appliance component in some topologies | .NET Core |
| Configuration layer | App Factory Studio, App Factory backend, Factory configuration database | Angular, .NET Core |
| Business database | Application data of the configured applications | Microsoft SQL Server |
Clients call the gateway over REST, through the ingress or reverse proxy. The gateway calls the engine and the other components over gRPC. The engine reads the configuration produced in App Factory Studio and reads and writes business data.
Domains
Each application built on App Maker has its own domain. A single configuration store manages the configuration of all domains. Each domain stores its application-specific business data in its own database, and portals present the functionality of one or more domains.
A domain can have several versions, so changes to processes can be captured over time. See Key concepts for how domains, modules and workflows relate.
Functional architecture
From a functional point of view, the platform provides these components:
- external access: online access to configured features and static content, through the external portal, info kiosk or mobile app;
- internal portal: access to all configured features and to the security and configuration components that are not available externally;
- integration and orchestration: connects systems, exchanges data and manages interactions between components;
- security: provides security for the whole platform in one consistent model;
- integrated administration and configuration: builds features through visual configuration, without writing code or compiling sources;
- database.
Integration architecture
The integration and orchestration component, the API Gateway, is the single entry point for external requests. It routes requests to the right microservices and handles authentication, authorization, access, logging and the aggregation of responses from several services.
| Link | Protocol | Characteristics |
|---|---|---|
| Front-end clients to API Gateway | REST over HTTP | JSON or XML payloads, native caching, TLS encryption, support for load balancers |
| API Gateway to services, and between services | gRPC over HTTP/2 | Binary serialization, multiplexing, synchronous and asynchronous calls, unary and streaming calls (server, client and bidirectional) |
Integration works in two directions. App Maker reaches third-party systems through plugins, and exposes its own APIs to other systems. All interfaces support several languages and run in desktop and mobile web browsers.
Infrastructure architecture
The architecture supports high availability for all components and runs in a fully virtualized environment. The recommended topology uses Docker containers orchestrated by Kubernetes, OpenShift/OKD, Docker Swarm or an equivalent.
Containerized components include the web front ends, the App Maker Gateway, the App Maker Engine and App Factory Studio. Auxiliary components, such as authentication or file processing, are added according to the configuration. Orchestration provides:
- load balancing through an ingress controller or service mesh;
- auto-scaling based on traffic, CPU and memory load;
- rolling deployments;
- failover and high-availability policies.
Components with external access can be placed in a DMZ and communicate only over HTTPS. Traffic between the DMZ and the internal network passes only through secured services behind a reverse proxy.
High-availability reference topology
The reference topology has four App Maker servers in two pairs. One pair serves internal users and the other sits in the DMZ for external clients. Each pair sits behind a network load-balancing cluster with a virtual IP address. The databases run on a SQL Server failover cluster with a storage area network. Firewalls separate the internet, the DMZ and the internal network.
In one variant, a reverse proxy in the DMZ publishes the external portal and forwards API and content requests to the internal servers. The topology is a high-availability scenario and can be adjusted to the customer's network and security setup.
Security architecture
A dedicated security module handles authentication and authorization for all applications and services in the platform. It is not duplicated in each microservice, and business services do not implement authentication themselves.
- The API Gateway manages authentication centrally and can delegate it to an external identity provider over OAuth 2.0 or OpenID Connect.
- The gateway validates JWT tokens or encrypted HttpOnly, Secure cookies, then propagates the user's identity and permissions to downstream services.
- Each microservice validates access rights again, with support for fine-grained authorization based on scopes and claims.
- The platform integrates with Keycloak, LDAP, Active Directory, SAML and SCIM.
