Right now, the link() method that Shard and Gateway must define is somewhat-awkwardly returning a relationships object. Currently, the self property inside of Gateway isn't even used.
However, this is done so that it's a non-breaking change to include Gateway-to-Gateway at a later date. By moving to an object now, that means that developer can opt into this topology by simply adding new keys to the object. The valid Gateway#link return objects will look like this:
type Node<T> = Gateway<T> | Shard<T>;
abstract class Gateway<T> {
abstract link(bindings: T): {
self: DurableObjectNamespace & Gateway<T>;
child: DurableObjectNamespace & Node<T>;
} | {
self: DurableObjectNamespace & Gateway<T>;
child: DurableObjectNamespace & Node<T>;
parent: DurableObjectNamespace & Gateway<T>;
gateway: string;
};
}
Similar to Shard, the Gateway will have to know what it is (self) and what its parent class and parent identifiers are. This is so that Gateways can gossip with one another (use case?) and so that it can forward live-count information to its parent.
Right now, the
link()method thatShardandGatewaymust define is somewhat-awkwardly returning a relationships object. Currently, theselfproperty inside ofGatewayisn't even used.However, this is done so that it's a non-breaking change to include Gateway-to-Gateway at a later date. By moving to an object now, that means that developer can opt into this topology by simply adding new keys to the object. The valid
Gateway#linkreturn objects will look like this:Similar to
Shard, the Gateway will have to know what it is (self) and what its parent class and parent identifiers are. This is so that Gateways can gossip with one another (use case?) and so that it can forward live-count information to its parent.