Component types

A closed list of values for type, each with its own icon. Anything else is rejected rather than guessed at.

Accepted values

The type of a component picks its icon and says what kind of thing it is. It is a closed list of 10 values: a type outside it is rejected, with the offending line named, rather than quietly turned into a service.

service

A deployed process that serves requests or handles events. The default for anything you run.

application

A deployable unit made of several parts, where the parts are not worth declaring separately.

frontend

A user-facing application. It calls other components; nothing inside the system calls it.

api

A gateway or published interface that fronts other components rather than holding logic of its own.

database

A persistent store. Declare it when a component reads or writes it, so the dependency is visible.

queue

A broker, topic or stream. Publishing to it and consuming from it are two relationships, told apart by direction.

worker

A long-running consumer that processes work off a queue rather than serving requests.

job

A scheduled or triggered task that runs and exits.

library

Shared code other components depend on but which runs nothing of its own.

external

A system outside your boundary: a payment provider, another team's service. Usually declared under external rather than components.

The chips above are grey because a type has no colour of its own. Hue belongs to the component, not to its kind.

Assigning a hue

Hue is assigned, never declared — there is no hue field. Each component the repository declares takes the next of 6 hues in id order, and keeps it on the rail dot, the index card and every chip that references it, so a component looks the same everywhere. The order is stable, so the colours survive a re-import.

8 components in id order. The palette of 6 then starts again, so hues repeat in a large repository — a colour groups nothing, it only identifies. Anything under external, and any target nothing declares, stays grey.