Create countertop topology generation

[slifty]

Description

This PR adds the first portion of the countertop, which is the central workspace of the TV kitchen ultimately responsible for setting up the appliances and data streams to process all unique data streams.

Specifically, it adds the countertop components necessary to register appliances and convert a set of registered appliances into a data flow topology (the various data paths between sections of the countertop which will transform that data into new formats).

This begins to implement some of the API described in #82.

Since this is the first countertop PR, it defines a few key classes which will be expanded on in future PRs:

• CountertopCoordinator defines the developer API -- developers will be working with this entity directly. It is where new appliances are registered. It generates the rest of the countertop.

• CountertopStation represents a section of the countertop dedicated to a single configured appliance. There will likely be more than one copy of a given appliance (one copy per data stream).

• CountertopStream is an object that is used to (A) determine how many appliances should exist in a given station and (B) determine which appliances should process a given payload.

Issue #23 goes through a fair number of example topologies.

This PR does not completely finish the countertop, but rather it creates the API for registering appliances and converts a list of appliances into a topology which the countertop will use to set up stations and route packages between stations.

Due Diligence Checklist

• Tests
• Documentation
• Consolidated commits
• Relevant labels assigned

Steps to Test

The best way to test this is using your _sandbox.js

Here's an example sandbox:

import { IAppliance } from '@tvkitchen/base-interfaces'
import CountertopCoordinator from '%src/components/countertop/CountertopCoordinator'

class SourceAppliance extends IAppliance {
	static getInputTypes = () => []
	static getOutputTypes = () => ["STREAM.CONTAINER"]
}

class CaptionAppliance extends IAppliance {
	static getInputTypes = () => ["STREAM.CONTAINER"]
	static getOutputTypes = () => ["TEXT.ATOM"]
}

class LineAppliance extends IAppliance {
	static getInputTypes = () => ["TEXT.ATOM"]
	static getOutputTypes = () => ["TEXT.LINE"]
}

class ComplexAppliance extends IAppliance {
	static getInputTypes = () => ["TEXT.LINE", "STREAM.CONTAINER"]
	static getOutputTypes = () => ["IMAGE.FILE"]
}

const countertop = new CountertopCoordinator()
countertop.addAppliance(SourceAppliance)
countertop.addAppliance(SourceAppliance)
countertop.addAppliance(CaptionAppliance)
countertop.addAppliance(LineAppliance)
countertop.addAppliance(ComplexAppliance)
const topology = countertop.updateTopology()
console.log(topology)

Deploy Notes

None

Related Issues

• Related to Create the countertop #23
• Related to Create the SousChef #30
• Resolves Define the countertop API #82
• Resolves How should appliances be installed? #65

[slifty]

@chriszs This is not final, but what's in here is ready for review. Specifically the toplogy generation.

I'm going to be adding tests and documentation, but 85% of the complexity of the PR is already in here.

[chriszs]

Still reviewing, but here's what I've got so far.

[chriszs]

I'll admit to still not fully understanding parts of this, but I suppose if it's doing what it's supposed to, then I don't have to.

[chriszs]

Could this just use .values()? Do we need both types of methods?

[slifty]

I wonder if maybe I didn't know about .values when I wrote this.

I'll go through and see (either way yes I think you're right, and we don't need this method at all thanks to values).

If I remove getTributaryArray then I would replace getTributaryMap with getTributaries

[slifty]

One thing: .values returns an iterator (not an array).

Should we have a helper method built into the class, or should folks have to just write Array.from(stream.getTributaries().values()) when they want the array.

[chriszs]

That does seem wack.

[slifty]

I'll keep the method for now, but will implement it using values / the snippet above instead of the .each()

[slifty]

All right -- I am going to merge this despite not reaching perfect self-documented clarity because:

1. It may change fundamentally some day anyway
2. It does have an appropriate level of documentation (e.g. all methods are documented), and explaining the overall algorithm may be better suited for the website documentation page.