Closed Eduard-Hasa closed 2 years ago
@kwhitley Is this project alive and working in the current release of cloudflare durable objects?
@Eduard-Hasa There is an issue with the persistence in this current version. I have solved it locally for a Chrome extension I just released (backed by DO + KV), but just haven't decided whether to change the interface or not before publishing the changes.
I'd recommend jumping over to https://github.com/kwhitley/itty-durable/discussions and adding any input/suggestions you can!
v1.x
is being wrapped up today and will be released, fixing a few of the issues of this alpha release. It works well with the current CF Workers implementation, and is in used in production on several projects.
Exciting!! Thank you for your awesome work.
Thanks Eduard! (also for your patience!!)
Super stoked by what this allows, and wouldn't dream of using DO without something like this personally. Just hard to look at code with all that boilerplate, haha.
Likewise. Could you please describe what your changes were once released. Like what you did about persistence and etc. Also one thing that a lot of libraries lacked on is showing examples of a variety of api development that one would approach with these libraries. For example A post request to the worker that would then make another post request to a DO to access the state. And also a websocket that would then notify another worker or frontend react client that an order has been updated for example.
Sure!
v0.x
, by design. In the first version, I'm thinking of only exporting the factory function createIttyDurable(options?: object): class
so that people aren't confused using exported classes with pre-baked options.autoPersist: true
.autoReturn: true
), which helps with usage within large-payload DOs (where sending that data back to the worker is expensive and therefore returns should be explicitly controlled). This makes simple demos slightly more verbose, but helps avoid danger by explicitly require opting in to automatic behaviors.These features being off by default reverse the "magical" assumptions of the original release... all the magic is still there, but you have to ask for it.
I may offer one-prebaked class (e.g. AutoDurable
) that turns it all on by default, as a convenience... undecided on that. By skipping that in the beginning, I don't lock the API in or require a breaking change by reversing the decision.
I really love the idea behind itty-durable and was wondering if this is something that you guys plan to maintain in the future?
Is it usable/stable right now for basic documented functionality?