Service configurations are formatted in json and are expected to be found at the root of your application in an
The name of your service. Used primarily by consumers to broker connections. Also see the publishing guide for information on namespacing.
The version number for your service. Architect's registry enforces strict semantic versioning to allow for flexible referencing from consumers.
A short, human-readable description of your service.
(optional) An array of keywords that describe your service for easier indexing and discovery.
A string citing the language used in the development of this service. Architect uses this for automatic code-gen when consuming or publishing services that use strict interfaces like gRPC.
See the docs on supported languages to see which languages you can reference.
The interface details for your service:
type(required) - The interface type this service uses to make itself available. One of
grpc(others coming soon).
definitions- An array of paths to service definition files (e.g. protobuf files). Required for strict api types like
(optional) A dictionary detailing the other services this service depends on. Dictionary keys must always be the name of the service (including namespace) and values must be a valid version number of the service to be integrated with.
Note: See the docs on installing unpublised services for details on how to cite services that haven't been published to the registry yet.
(optional) A dictionary outlining the parameters this service accepts in order to run. Parameter keys must be a unique variable name, and the values are objects containing the following keys:
description(optional) - Short, human-readable description of the parameter
default(optional) - A default value for the parameter if one isn't registered with the environment
alias(optional) - Another name for the variable to make it easier to refer to in your application
required(default: true) - An assertion of whether or not the parameter is required for your service to run
(optional) A dictionary inventory of the data stores required by this service. Configuration details for your data stores can be found in the attaching datastores guide.
A string array of notification events this service publishes. Architect uses this list to validate subscriptions and broker connections between publisher and subscriber.
A nested dictionary containing details of the services and corresponding events being subscribed to. Top-level keys are the names of services being subscribed to, and inside each service key is a dictionary with keys referencing event names.
uri(required) - URI at which your service subscribes to an event
headers(optional) - Dictionary containing headers that are required to be submitted from the notifier to this service for validation
For further configuration examples, check out the guide on subscribing to notifications.