Replies: 1 comment 1 reply
-
Hi there, The goal of this example is explained in the main worker. Basically it is an experiment to see how tiered websockets work when the browser client websocket is terminated in the entry-point bundled worker, which then is a client of another DO-terminated websocket. Tiering using ws terminated in entry-point workers is interesting since they are much cheaper and could potentially run in more data centers, but they appear to be fragile in practice. You'll get strange "not allowed to issue websocket requests outside of the initial request context" type errors. And of course they have different cpu/runtime limits than DOs. If your goal is to create stable GraphQL subscriptions, I would encourage you to use DO-terminated websockets, they should work well. If you suspect you'll need more than about 1000 connections in the same instance, you can set up tiers among DOs that fan out. ColoFromTrace is a way to detect which colo a DO is running in, since that information is not included in DO fetch requests, unlike normal entry-point worker requests. Hope that helps |
Beta Was this translation helpful? Give feedback.
-
Hey,
I just wanted to have a discussion on your tiered-websockets-worker example as its the only one I could find that attempts this.
Does it work? Does it work well? What are the drawbacks of the system?
I think this sort of thing will be crucial for a subscription based GraphQL architecture is that correct?
BTW in your example what is the purpose of this ColoFromTrace class? https://github.com/skymethod/denoflare/blob/master/examples/tiered-websockets-worker/colo_from_trace.ts#L1
Cheers,
Mike
Beta Was this translation helpful? Give feedback.
All reactions