Evaluation Guide

Runtime architecture

Genus Services provides the application services responsible for interpreting and executing your no-code applications in a cloud-native microservices architecture. In this section, we will explain the architecture behind Genus Services as well as the important aspects behind the runtime execution.

  • Genus Services reads and interprets models from the Metadata Repository. Based on this interpretation, Genus Services provides services to users through Genus Desktop, Genus Web, and API interfaces.

    Differing from most no-code platforms, Genus interprets and executes the model directly. Consequently, there is no code generation or compilation involved in the deployment and execution of models.

    This also implies that there are no options for injecting or extending your Genus applications with custom code. This pure, codeless approach to metadata interpretation is the only way to achieve truly sustainable business applications where the platform can evolve and be modernized without impacting your model. Additionally, it is the only way to truly ensure that the security configured in the application is not broken. However, should you need to interact with custom code, this can be achieved by using REST or SOAP services.

  • The Genus Services runtime consists of the microservices to interpret and execute your applications. The architecture is based on the principles of coupling and cohesion, where each microservice has a clear role or responsibility and a clearly defined interface.

    All microservices are programmed in the language most suitable for the tasks they shall perform. Current programming languages include JavaScript (Node.js), C# .NET Core, C# .NET Framework and Delphi (Pascal).

    All microservices are stateless and dynamically scalable, both as multi-containers and multi-threads. The client requests include all necessary information and will be validated server-side to maintain security and consistency.

    The microservices are 100% based on Kubernetes and are implemented as a mix of both Linux and Windows Docker containers. This allows for Genus Services to be deployed to all major cloud providers (e.g. Microsoft Azure, Amazon Web Services, or Google Cloud) as well as on-premises.

    The microservices are deployed to a Kubernetes cluster, and authentication within the cluster is token-based.

Runtime architecture components

  • Responsible for scheduling and executing modeled agent jobs, which are comparable to batch jobs, running server-side.

  • Authenticates users via Identity Providers

  • Responsible for authorizing access to different parts of the application through permissions on a metadata level.

  • Responsible for handling requests from standard CardDAV clients, such as Microsoft’s, Apple’s, and Google’s contact apps. Contact lists or address books can be defined in Genus Studio and can expose any contact-related data to third-party applications.

  • Responsible for executing CRUD (Create, Read, Update, Delete) commands on the customer data based on the metadata. This is an essential service to enable codeless, metadata-interpreting applications.

    The service verifies the CRUD commands against the metadata before executing them, to ensure that they follow configured rules for data integrity, permissions, and other security aspects.

  • Responsible for aggregating data and maintaining data marts, enabling advanced dashboard- and analytics functionality. The microservice handles requests and contains logic for running queries towards the data marts.

  • Helps optimize the communication with underlying databases, building on statistics and Data Definition Language (DDL) requests. The service also provides support for reverse engineering of databases by reading database information (tables, columns, indexes, etc.)

  • Provides file- and file format services, including email format services and both client- and server-side document merge. This microservice is partly built on top of the third-party library Aspose.

  • The Gateway Service routes all incoming requests to other microservices within the runtime environment.

  • Delivers sections or articles to our desktop- and web clients from the markdown-based help documentation of our platform.

  • The ingress is used to control the routing of incoming traffic. A controller interprets the ingress rules and routes traffic to the correct microservices, while the load balancer routes the external traffic into the Kubernetes cluster.

  • Delivers natural language translations and word lists in an i18n format. Enables the Genus applications to be accessible in several languages.

  • Responsible for commands towards Kubernetes to control the pods in a namespace, fetch a microservices version, assign trace level, and route to green/blue namespace, etc.

  • Collects live update messages from other Genus microservices.

  • Reads messages in queues (stored in Redis) and sends live updates and trace messages to Genus Web and Genus Desktop clients via web sockets.

  • Used by Genus Studio to read and write application models (metadata) to and from the Metadata Repository. This service is not used by Genus Desktop, Genus Web, or APIs.

  • Responsible for reading metadata from the Metadata Repository to provide application model information to Genus Web, Genus Desktop and APIs.

  • Enables the consumption of REST services exposed by third parties from your Genus application.

  • Exposes REST services and handles calls from third parties. REST endpoints are subject to the same security model as all other communication with your Genus applications.

  • Responsible for asynchronous mail delivery from your Genus application.

  • Enables the consumption of SOAP services exposed by third parties from your Genus application.

  • Exposes SOAP services and handles calls from third parties. SOAP endpoints are subject to the same security model as all other communication with your applications.

  • Responsible for interfacing with the supported database engines, such as Microsoft SQL Server, Oracle, and DB2. This includes database driver handling, threading, etc.

  • Provides functionality for streaming of data, including videos, to/from databases or BLOB-storage providers.

  • Responsible for monitoring and collecting trace messages from other Genus microservices and making these available to clients through Redis and the Message Subscription Service.

  • Handles requests from any Webcal client, such as calendar apps from Microsoft or Apple. Calendars are defined in Genus Studio and you can expose any calendar-related data in your application.

  • Supports Microsoft Office Online clients reading and editing documents stored in your Genus application. WOPI is short for Web Application Open Platform Interface Protocol.