Consider an improved way of referencing containers in cloud.Service

This is not a priority, but I wanted to capture this idea.

Consider this code:

let redisPort = 6379;

let redisCache = new cloud.Service("voting-app-cache", {
    containers: {
        redis: {
            // <snip>
            ports: [{ port: redisPort }]
        },
    },
});

let frontend = new cloud.Service("voting-app-frontend", {
    containers: {
        votingAppFrontend: {
            // <snip>
            environment: { 
                // using a string to reference the "redis" container
                // is there a better way to reference the port?
                "REDIS": redisCache.getEndpoint("redis", redisPort).then(e => e.hostname)
            }
        },
    },
});

To reference the redis container from the frontend.votingAppFrontend container, I have to use the string value redis. It’s also annoying that I have to pass in the port, though I realize it will default to the first open port. I saw that ports are not named in Docker Compose, so that might be a hard thing to change.

At first glance, I’m not sure how we would make the types stronger (looks like dependent types), but perhaps there’s a way.

Other than promises, this is really the only flaw of an otherwise lovely program.

[lukehoban]

This is something that’s bugged me with our current APIs, btw, since the “single container” case entails some extra concepts that may not make sense. (“What, I just wanted to run a single container, why would I have an array of them?”)

Here’s a thought - we could split the containers part of the arguments to Service into a separate parameter from the other options (which are often not needed) and then offer two overloads:

export interface ServiceConstructor {
    new (name: string, containers: Containers, args?: ServiceArguments): Service;
    new (name: string, container: Container, args?: ServiceArguments): Service;
}

The later would be the “simple” model, and would name the container the same as the name provided to the Service constructor.

Donna’s example would look like:

let redisPort = 6379;

let redisCache = new cloud.Service("voting-app-cache", {
    // <snip>
    ports: [{ port: redisPort }]
});

let frontend = new cloud.Service("voting-app-frontend", {
    // <snip>
    environment: { 
        // using a string to reference the "redis" container
        // is there a better way to reference the port?
        "REDIS": redisCache.getEndpoint("redis", redisPort).then(e => e.hostname)
    },
});

This also makes the multi-container case more pleasent as you don’t need to say the word “containers” for something that will always be there.

[joeduffy]

I would think we want to show the simple use case. I suspect many (most) services will just have a single container and single exposed port. This is something that’s bugged me with our current APIs, btw, since the “single container” case entails some extra concepts that may not make sense. (“What, I just wanted to run a single container, why would I have an array of them?”)