We will discuss and clarify frequently-used terms in Knowru so that users can easily follow the later part of this user guide.

Creating and managing microservices involve IT experts from various roles and functions. For the role perspective, Knowru provides two user types: managers and members. Managers have permissions to do anything inside the platform. Members do not have any permission unless explicitly given so. The document will later discuss permission types and how to share resources with other users. For different functions, Knowru provides groups, a collection of users that can have same set of permissions. In a typical scenario, an organization has two groups: analytics and developers.

Users upload their source code to create runnables and runnable versions. You can think of a runnable as an API. A runnable version is a version of the API. You can make requests to endpoints of both a runnable and runnable version and they will work fine. When you make a request to a runnable, the runnable looks at the configuration that you set on what versions to route the request to (each version can have a different probability of receiving a route) and routes the request to the runnable version.

Runnable versions (or shortly versions) of a runnable are assumed to be related to each other. While not enforced, it is highly recommended to keep a consistent structure of input and output across different versions. To create a version, users need to upload three types of files: knowledge, requirement and miscellaneous files.

  • Knowledge file: a file specifying how to process input and return output (required)
  • Requirement file: a file specifying dependencies of a microservice (optional; if not provided, interpreted as no dependency required and an empty file will be automatically created)s
  • Miscellaneous files: files required to perform the logic inside a knowledge file (optional).

Once a runnable version is created, users can test new runnable versions before exposing them to other users. A test is a collection of scenarios. A scenario consists of input JSON, expected JSON and maximum response time. Once a test is set up, users can apply the single test to multiple versions to make sure they behave expectedly.

Now external users make requests to runnables. A run is a transaction, a record of the request coming in and the response going out.