Vision App Maker integrates with other systems in two directions. It calls external systems through plugins, and it exposes APIs that external systems can call. All client traffic enters through the API Gateway, which routes it to the backend services.
Layers and components
The platform is organized in three layers, each with a defined role. Clients never call the backend services directly.
| Layer | Components | Role |
|---|---|---|
| Client (front end) | Internal and external portals (React), info kiosk applications (React), mobile app (React Native), web browsers | User interface and UI logic; calls the APIs published by the API Gateway |
| API Gateway | App Maker Gateway (.NET Core) | Single entry point; publishes the public APIs used by clients and the internal APIs for content management |
| Services (back end) | App Maker Engine (.NET Core) and other microservices or monolithic services | Business logic, database access, data processing and event handling |
App Factory Studio, the configuration interface, stores application configuration in a configuration database. The App Maker Engine reads that configuration and runs it. Each domain keeps its business data in its own business database.
Communication protocols
The platform uses one protocol family for client traffic and another for service-to-service traffic.
| Connection | Protocol | Characteristics |
|---|---|---|
| Clients to API Gateway | REST over HTTP, through an ingress controller or reverse proxy | Standard APIs reachable from the browser; JSON or XML payloads; native HTTP caching; TLS for encryption and authentication; supported by API gateways and load balancers |
| API Gateway to App Maker Engine, and between microservices | gRPC over HTTP/2 | Compact binary serialization; multiplexing and low latency; synchronous and asynchronous calls; lower bandwidth and CPU use than JSON-based calls |
The gRPC layer supports four call types:
- request-response: the client sends one request and receives one response;
- server streaming: one request, several responses;
- client streaming: several requests, one response;
- bidirectional streaming: client and server send data continuously.
gRPC APIs can change without breaking compatibility. They integrate with OAuth 2.0 and run under Kubernetes or other orchestrators.
Role of the API Gateway
The API Gateway is the central entry point for all external requests. It checks each request and forwards it to the right microservice. Its functions are:
- routing to the correct service, with load balancing;
- response aggregation: one response to the client built from several services;
- authentication and authorization: token or cookie validation before a request reaches the back end;
- single sign-on for unified access;
- rate limiting and throttling;
- response caching to reduce back-end load;
- logging of requests and responses for audit, debugging and metrics;
- request and response transformation: payloads, headers, paths and formats;
- CORS rules between front end and back end;
- SSL termination, IP whitelisting, input validation and DDoS protection.
How external systems connect
Outbound: plugins
App Maker reaches third-party systems through plugins, also called connectors. Configurators set them up in App Factory Studio and use them in business rules, interfaces and any workflow step. The documented operations include:
- PDF processing: watermarks, barcodes and QR codes, signing, labels;
- file handling in network locations or document repositories, with metadata sets;
- file archiving with a configurable archiving policy;
- e-mail: sending messages and reading them with recipients, subject, body and attachments separated;
- HTTP service calls and RPC (remote procedure call) calls;
- database queries, writes and query execution;
- signature pad integration.
The integration layer is modular. Vision can develop new connectors for specific systems, and configurators then use them from the visual interface.
Inbound: APIs
External systems call App Maker through the APIs published by the API Gateway. General-purpose APIs start and load process instances, read and set parameters, change workflow states and run configured rules. Administrators can also publish custom REST endpoints and MCP tools, each running a configured rule.
Network placement
Components with external access can be placed in a DMZ. They reach the internal network only through secured services behind a reverse proxy. The external portal does not allow direct access to the database.
All components run as containers compatible with OCI and Docker. They can be orchestrated with Kubernetes or OpenShift.
