You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, the link() method that Shard and Gatewaymust 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:
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.
The text was updated successfully, but these errors were encountered:
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?
@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
Right now, the
link()
method thatShard
andGateway
must define is somewhat-awkwardly returning a relationships object. Currently, theself
property inside ofGateway
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: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.The text was updated successfully, but these errors were encountered: