About this Page

With ApiOmat 20.03, the first version of microservice generation and all required components were released. This page gives an overview of current technology choices and current limitations of service generation. It will be continuously updated in the future.

Components and technology

We split the functionality of ApiOmat into several microservices to provide higher scalability, so you will need to install all of the following components:

Service	Functionality	Description
Consul	Service discovery	Consul is used for service discovery/registry. Each service needs to register itself to Consul to be able to communicate with other services.
YAMBAS	ApiOmat backend	YAMBAS is the backend of the main product. It currently contains the business logic to manage accounts, applications, modules, UIs and classes, and SDK generation.
Dashboard	ApiOmat frontend	Dashboard is the current frontend that helps you interact with the functionality of all the other components
Brewer	Microservice generation service	Brewer provides functionality to generate a microservice artifact out of given ApiOmat MetaModels (classes).
Innkeeper	Hosting service	Innkeeper hosts your maven repository where all your generated services can be hosted.
Executor	Deployment service	Executor provides deployment functionality to start and stop your generated service in an environment such as Nomad (or later Kubernetes).
Gearhead	Configuration service	Gearhead stores and loads service configuration properties.
Explorer	ApiDocs service	Explorer gathers the published API documentation of all registered services and makes it available under a single UI.
Instructor	Documentation service	Instructor contains the public documentation of all ApiOmat product components.
Dispatcher	Gateway service	Dispatcher helps you route an external IP to the registered services which should be available to outside applications.

For service discovery, we've chosen Consul from HashiCorp. Besides our known product components ApiOmat YAMBAS and Dashboard, we moved some functionality to several microservices as described in the above table.
These microservices are Spring Boot Applications which can be installed and run on different environments (see the Installation section for more details). Ribbon (framework from Netflix, integrated into Spring Cloud) is used for load balancing during communication between the services. A declarative web service client called Feign, which is also compatible with Spring Applications, is used to interact between microservices.
Brewer also generates services as Spring Boot Applications and delivers them as Maven projects. Currently, these generated artifacts can only be deployed to Nomad environments.

Limitations

This section contains a list of limitations and disabled features of microservice generation. It compares the known features of ApiOmat modules from previous versions with the new service generation concept, giving you an overview of currently missing features and planned future changes.

Limited Staging Concept

Currently, only the LIVE staging system is used for generating and deploying a service in ApiOmat. We are planning to fully support the other systems TEST and STAGING, which you already know from working with ApiOmat modules, in the future.

Limited Inheritance / References between different Services

Currently we do not support inheritance and references between different services.

Although it is possible to include the generated library of a service as dependency to another service that wants to use the Class Models and the corresponding API Clients. See the chapter about Using other Services for more information.

Limited Service Deployment

It is possible to deploy and start generated services via the ApiOmat Dashboard. Currently, the port of the running instance of your service is chosen by Nomad from between 20000 and 32000 (default dynamic port behavior of Nomad) when you start the service via Dashboard. Adding custom execution parameters to your service deployment is also disabled for now.

One future target is the deployment of generated services to your personal Kubernetes instance. The Kubernetes integration is currently disabled due to its experimental state, so generated services can only be deployed to Nomad.

Additionally, the current deployment workflow only supports Java artifacts (JAR/WAR archives). The option to deploy a Docker image is disabled for now.

Limited Service Hosting

In order to deploy your generated service artifact to Nomad, it needs to be hosted on a repository. For that purpose, we provide our ApiOmat Innkeeper service which is automatically called during microservice generation (by the ApiOmat Brewer service). This also means that you are currently limited to storing your generated service artifacts in the Maven repository within Innkeeper.

Limited Authentication and Authorization for Service Deployment

Authentication and authorization are currently based on the Customer objects of ApiOmat YAMBAS.
In other words: When a customer triggers a service deployment in the Dashboard, their login credentials are used when calling ApiOmat services during the deployment process.

Disabled Invisible Classes

With native modules, you can hide classes by setting them invisible. This feature is currently not available for microservice classes.

Disabled CustomMeta-, Example- and Validation-Tags

With native modules, you can set an example text and CustomMeta data for a specific class attribute which will then be generated into the class file for your module developers. This is currently deactivated for attributes of service classes.

Also, the validation tags such as Minimum Length, Maximum Length and Regular Expression are disabled for service classes.

Disabled custom Role and Auth Classes

For ApiOmat module classes, it is possible to define custom role classes and custom authentication classes for accessing class objects in your application. This feature is disabled for service classes, which means that currently only the default ACL mechanism of ApiOmat can be used.

Disabled Service with custom Git Repository

As a module developer, you can create a native module which is connected to a Git repository. This feature is currently disabled for services.

Disabled Dashboard Log Integration for Services

In native modules, you can have your module's logged messages sent to the Dashboard and displayed there. This feature is currently disabled for services.

Disabled Dashboard Custom REST Endpoint Integration for Services

With native modules, any custom REST endpoints you create will be displayed in the Dashboard and can be called from there. This feature is currently disabled for services.

Classes can only be deleted "Code-First"

If you upload a service at least once, it is no longer possible to delete any of that service's classes over the dashboard.
This is due to the following: When the code of your deployed artifact (where the class is still present) is merged with the modeled classes (where you deleted the class) you created over the API/Dashboard, the class will be present again after compilation.

This is because we try to make sure your code is compilable: A service class could be referenced somewhere, such as in another service class, and we have no way of changing the code of the other class.
So if you want to delete a class, remove it locally (code-first), then build and deploy the service.

Service Limitations