Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow Gateway-to-Gateway topology #2

Open
lukeed opened this issue Sep 8, 2021 · 2 comments
Open

Allow Gateway-to-Gateway topology #2

lukeed opened this issue Sep 8, 2021 · 2 comments
Labels

Comments

@lukeed
Copy link
Contributor

lukeed commented Sep 8, 2021

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.

@lukeed lukeed added the future label Sep 8, 2021
@lukeed lukeed mentioned this issue Nov 18, 2021
@jacwright
Copy link

jacwright commented May 24, 2022

If you are looking for a use case for this feature, I think creating Groups by locale ensures a user is connected to a DO which is close, while Gateway-to-Gateway communication allows them to communicate with others globally. I was thinking of it as Group -> Locale -> Replica, but this works too. When a request comes into my worker, I would grab req.cf.colo (or region or continent, depending on the number of users I expect to have) to assign that connection to a closely (or more closely) located DO. But I'd still like people to connect from all over the world with each other.

Or should I add location-aware as a separate feature request?

@tobad357
Copy link

@lukeed this would be exactly why we would want it.
To create groups in regions / countries but still be able to update them all when say content changes globally

Right now we can awkwardly do it by either use the Rest API and find all DOs or have static groups

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants
@jacwright @tobad357 @lukeed and others