Creating a service

Learn how to create and configure a service that can be published and deployed with Architect

The service configuration manifest is the means by which Architect's platform indexes your service, builds dependency graphs, and brokers networking between deployed services. It's a crucial addition to your application image that enables your service to provision and automatically connect to peer applications and other network dependencies.

Metadata

Just like your favorite package manager, services depend on metadata like a name and description in order to be understood and referenced by consumers. Once your service has been published to Architect's registry, it will be discoverable and installable via the platform and CLI for others to reference.

{
    "name": "architect/shopping-cart",
    "description": "Service used to manage customer shopping carts",
    "keywords": ["shopping", "cart"]
}

Parameters & credentials

Often times services are configurable to do anything from toggling between log levels to connecting to storage buckets. In order for Architect to ensure that consumers have configured services properly, the parameters and credentials an application can or must receive need to be added to the service config file:

{
    "parameters": {
        "LOG_LEVEL": {
            "default": "info"
        },
        "AWS_S3_BUCKET": {
            "description": "Name of the S3 bucket to store product thumbnails in",
            "default": "product-thumbnails"
        },
        "AWS_ACCESS_KEY_ID": {
            "description": "ID of an AWS access key that has access to cited S3 bucket"
        },
        "AWS_SECRET_ACCESS_KEY": {
            "description": "Secret used to authenticate in conjunction with the cited access key"
        }
    }
}

Exposing the interface

Services need to broadcast the interface they use for communication so that upstream callers can resolve them appropriately. Architect uses this to provide informative context to developers seeking to consume the service, but also uses the type to configure ingress/engress rules for interprocess communication (e.g. ensuring the right protocol is used):

{
    "api": {
        "type": "rest"
    }
}

See reference docs for available all supported API types