That is certainly part of the vision for DOs, but that won't be part of the first release I would im
That is certainly part of the vision for DOs, but that won't be part of the first release I would imagine..
HProbably a bit of finagling to get it GDPR-Compliant...
II've tried this in multiple ways now but can't get it to work. In short, I have a worker which manages incoming websocket connections for GraphQL subscriptions. Once a subscription comes in for a specific chatroom, a connection needs to be opened (or forwarded) to that durable object of that specific chatroom.
- The fetch method of stubs don't seem to return a webSocket, created and passed down as response on the durable object.
- I can't seem to pass a websocket to the durable object
EIt is already possible to restrict DOs only to EU colos.. https://developers.cloudflare.com/workers/runtime-apis/durable-objects#restricting-objects-to-a-jurisdiction
It isn't possible to automatically migrate a DO after it is created, especially if it has stored data already.
It isn't possible to automatically migrate a DO after it is created, especially if it has stored data already.
EI don't have a lot of experience with the websocket side of things @itswendell, but I feel it should absolutely be possible?
HOn the finagling, I meant getting the auto-migration to be GDPR-Compliant.
EOh no.. that is the easy part for a change 
.. the technical challenges are way harder tbh..
.. the technical challenges are way harder tbh..HMy brain hurts just thinking about it.
ESo does mine, so I am glad we have an amazing team working on that tbh.. 
HSo when you say it can't auto-migrate, does that mean that if a DO is initialize spawned in the US, but later terminated(Not Wiped), it can never be recreated in Europe?
II'm not so sure about that, I think the tricky thing is is that the connection comes starts in the Worker. The Worker creates and start's listening to WebSocket events with the client. Once a websocket event comes in that subscribes to a specific chatroom channel, I need to somehow communicate from the Worker to the Durable Object in real-time.
- I can't start a client / server from the Worker since there is no way I can pass the client in a Fetch request to the Durable Object.
- I can't start a client / server from the Durable Object, since the response of the durable object with fetch, doesn't include the webSocket.
EThat is correct. (Assuming it saved something to storage). If it didn’t save something to storage I believe it could.
IActually, I think I just made it work 
IIs there are a package / endpoint to make the
colo
JI believe they are standard IATA airport codes (https://en.wikipedia.org/wiki/IATA_airport_code) but that list posted yesterday (https://speed.cloudflare.com/locations) would be a nice cf-specific endpoint to use, for as long as it's around
An IATA airport code, also known as an IATA location identifier, IATA station code, or simply a location identifier, is a three-letter geocode designating many airports and metropolitan areas around the world, defined by the International Air Transport Association (IATA). The characters prominently displayed on baggage tags attached at airport ...
IThanks that helps, I think I'll try a simple free API reverse geocoding API for now, see how that works.
WAny plan to activate any DO here on SouthAmerica? It’s bad to always be routes to US … that ads to much latency that makes hard to test our software for any regression.
EYou get a specific bank of CPU time after every message. So I think if you don't send any messages, it will run out and terminate the DO at some point?
EI am sure we would love to activate DOs in more regions world-wide, but the requirements are to have multiple high quality dcs close together with multiple reliable network connections. And those are hard to find in areas like South America. I know exactly how you feel in Australia 
IIs there a list of locations for DOs? Whenever I create one in amsterdam it seems to be spawning in France. (according to reverse geocoding the IP of the DO).
IDo DOs auto migrate to a location once certain users from a specific location start using it more?
IThis was something that is planned for later right?
WThey open 25 new locations here on Brazil. But 100% of our workers traffic is only on one colo (GRU)…. I always assumed that we will get at last one DO location here. Because of not, it’s better to stick with something on google, aws or azure that’s full range products here.
WThey open 25 new locations here on Brazil. But 100% of our workers traffic is only on one colo (GRU)…. I always assumed that we will get at last one DO location here. Because of not, it’s better to stick with something on google, aws or azure that’s full range products here.
WI can live with aditional latency in while our app is in beta. But I was (maybe naively expecting) to got anything close before the end of the year.
CMake the chat room id part of the web socket request url to the worker. Then pass that same request to the DO stub’s fetch(). That way the web socket connection gets forwarded to the DO.
KIs there a way to get rid of the cold starts on the durable objects? When there is no request for a while it takes longer time.
CWait. Are you saying DOs will not be available in every colo even after GA?
CI’d have expected that DO to jump back to LAX, where it was originally. But it seems to now prefer to live in SJC. Is that to be expected for “named” DOs? That would make some sense since the DO’s location is cached in other colos.
M
COkay makes sense. What about DOs with unique IDs though? Their location doesn’t have to be cached, that was part of the design. Is that still true? Meaning even if that DO was temporarily resumed on another colo, would it “snap back” to the colo encoded one that is operational again?
M@kentonv_cf is best positioned to chime in when he’s back, but I assume you’re seeing it stay in SJC after maintenance moved it from LAX?
KTBH @brett_h knows the internals better than I do, but IIRC this is a known issue right now where after a failover to a different colo, we don't proactively migrate the object back.
EThat is my understanding.. there will probably be a much better coverage world-wide, but probably not every single colo. But I am not the definitive source on this
CDoes that apply to DOs with unique IDs too? Or just named DOs?