Type
New feature
Description
stubFromName convenience function on Durable Objects.
Benefit
As it stands, a worker of some sort is required to meaningfully interact with a durable object since, per the docs, the standard flow is to pull a stub from the DO to execute RPC functions against it. It occurs to me that this flow could be made more elegant by adding a stubFromName function to the base DurableObject class. My personal use case was finding myself frequently wrapping DOs in service bindings, and in most cases the first thing I do is write an equivalent convenience function in the service bindings and have every other binding call that to operate from the stub.
I’m sure there’s an architectural reason to wrap DOs in a worker but since DOs can be bound directly, it also occurs to me that on the off chance there is not an architectural reason to wrap always DOs in workers, then DOs could effectively exist on their own or otherwise have a no-op worker attached if the DO could internally expose a way to pull its own stub and use that in RPC functions. Barring that, establishing a pattern of internal service bound DOs or conventionally exposed workers that can avoid the boilerplate of id from name → stub from id would be a nice bump to usability, brevity, and elegance.
Apologies if this has already been floated and shot down internally, I am just armchair designing over here. Regardless, thanks for all the great tools, I’ve started shifting a healthy chunk of my tooling towards CF offerings and I appreciate all the work y’all are doing.