https://discord.cloudflare.com logo
Join Discord
Powered by
# durable-objects
  • a
    Is it an async function returning a promise?
  • t
    Yeah, that might have been part of it. I think something else was broken as well. Debugging crons and DO both could use some love
  • h
    Copy code
    Object Location

Not all Cloudflare locations support Durable Objects yet, so objects may not be created in exactly the same point-of-presence where they are first requested.

Currently, Durable Objects do not migrate between locations after initial creation. We will be enabling automatic migration in the future.
  • h
    So if a durable object is created at a specific location, it will never migrate at any point in the future?
  • h
    Once created, a durable object never goes down?
  • d
    sounds to me like the functionality just isn't there yet (but will be added sometime)
  • t
    It would be nice to have some sort of TTL for DOs, like "clean up this object if it hasn't been touched in seconds"
  • t
    I was able to get something interesting working in 1 day using DO with itty-durable (with some significant help!). My feedback - Docs for both DO and itty-durable could use some help, and a video tutorial would be very nice. - Interacting with DO from crons with itty-durable is currently not working (I think?), and I didn't get around to trying vanilla DO with cron. - Cron in general is kinda clunky still (no console.log, hard to know when your new code is running vs old code, it seems to take a while) - It's probably better to avoid crons if you can for now, and instead use timestamps in your objects if possible. - DO isn't super easy to get into, and itty-durable probably helps, but it's still really helpful to look under the covers as to how things work. If I could do it again I'd probably start with learning DO first, and add itty-durable after that for convenience. - Once you get it working it's very slick - @User is a super helpful person
  • k
    Agreed @theGagne re doing it the “hard” way first - no one would have any idea of the boilerplate that itty-durable removes otherwise, the price you pay for that magic, or more importantly, how to go “off rails” for specific use-cases. Def agree re documentation on both sides as well - and I’ll try to screen cast tonight to explain what my lib does/how it does it/how to handle edge cases, plus flesh out the README better. Working w you today was super helpful to remind me of all the gotchas! 🤓
  • t
    Curious to know why 
    Class.prototype
    didn't work?
  • k
    @Taral Well... it returns a proxy to the class instance, which may be the culprit... I’ll do some tests tonight, because I’m considering switching from a base class entirely and JUST proxying. Mind sharing the use case/what you’re trying to do?
  • t
    Reading your code out of curiosity. It's a good way to learn things.
  • t
    I saw the comment and thought "that's kind of how I'd do it, I wonder why it didn't work"
  • k
    Aaah gotcha! Well I’ll likely end up just using proxies on both ends, so users can test their class functionality w unit tests without having to worry about base class inheritance or pollution, etc. plus to get options in to the base class, I use a factory function to generate the class... that could all be replaced by a single wrapper function w options. Just more tedious to write (as @mehdiiii can back).
  • n
    I just noticed that requests (from the internet) to DO workers are missing the 
    cf
    (geolocation, etc..) property in the incoming 
    request
    object. I haven't found anything about a limitation regarding that in the docs, am I overseeing sth?
  • j
    Sounds like it's not exposed right now, and also not documented : ) https://discord.com/channels/595317990191398933/773219443911819284/829039258899185754
  • n
    ok, thanks!
  • m
    john is correct, it's not available, and likely won't be in the same way as it is for eyeball workers. 
    request.cf
    comes from FL (the nginx reverse proxy that handles all incoming requests to the cloudflare edge). Since durable objects requests come directly from other workers, FL isn't involved, so we don't have a value to pass for it. Passing through the 
    request.cf
    value from the eyeball isn't a perfect solution either, as some of the 
    cf
    attributes would be more useful if they referred to the durable object, rather than the eyeball worker (such as the colo name).
  • m
    if you are interested in the 
    request.cf
    values for the eyeball request, you can always include it in the body of a 
    fetch()
    to your durable object.
  • a
    👋 hello everyone, this API looks super cool. Kind of eager to try it, but I'm not 100% sure its a good fit for my current project, and it will be a lot of development work to understand how this scales. I feel like I might be misunderstanding the resource limits of workers in combo with durable objects, how they scale, and the pricing around a websocket connection. So if I'm making a real-time collaborative web app, using websockets to send and receive updates to a CRDT. I want to keep documents in a durable object's worker's memory whilst occasionally saving to a server. What happens when I get enough load that I use all the available worker memory (128mb)? Ideally it gets killed, and a couple of instances are spun up, which are load balanced across (like an autoscaling container), which would be great! but based on what I read here https://developers.cloudflare.com/workers/learning/how-workers-works, I'm not sure how this would actually play out. Also unclear to me, how do the runtime limits /pricing work if a worker is sustaining a number of websocket connections? does each message received count as new request providing another up to 50ms compute time, if so does each websocket message count as a "request" in terms of pricing? Hope these questions aren't to obtuse, thanks.
  • k
    For those that want to try the itty-durable abstraction around DO, I have a repo for you to clone/try out 🙂 https://github.com/kwhitley/itty-durable-example TLDR; your durables can be this simple:
    Copy code
    js
class Counter extends IttyDurable {
  increment() {
    this.counter = (this.counter || 0) + 1
  }
}
    with your Worker this simple:
    Copy code
    js
import { ThrowableRouter, missing } from 'itty-router-extras'
import { withDurables } from 'itty-durable'
export { Counter } from './Counter'

const router = Router()

router
  // access method on stub, indirectly firing method on DO instance, and returning a JSON Response of the DO contents
  .get('/:whichcounter/increment', withParams, withDurables(),
    ({ whichcounter, Counter }) => Counter.get(whichcounter).increment()
  )
  .all('*', () => missing('Are you sure about that?'))

export default { fetch: router.handle }

// GET /test/increment --> { counter: 0 }
// GET /test/increment --> { counter: 1 }
  • u
    With your itty-durable thing is it possible to use 
    storage.put
    storage.list
    directly? I havent tested it yet but it seems like from your usage in the Counter.js example that it only saves variables you add to the class and they all go into the "data" key on storage.put if I am reading the IttyDurable code correctly.
  • k
    sure... it follows the example pattern of 
    this.state.storage
    , so you can access that wherever you like
  • k
    yeah, that's default behavior... anything returned from 
    getPersistable()
    (you can override in child class) gets dumped as a single unit into the 
    data
    key. It's a simplistic approach that can be overridden via the 
    persist()
    and 
    initialize()
    methods
  • k
    easy to get off the ground on simple use cases till we can figure out the limitations and what all we need to ask of these things
  • k
    I just need to document all the paces to touch for custom behavior... but one of the advantages of using a base class is I allow near-complete takeover of the behavior ultimately
  • u
    Ok yeah wasnt sure if it would do that fetch autmation if I tried to do it that way. Thanks for the info
  • k
    Yep! You can even add custom routes onto the router inside the DO in your child constructor... which you could access from the worker. That’s a bit more advanced mode than the easy examples but still allows you to skip the fetch/initialize steps in your DO (superclass fetch handles that and passes off the request to the internal router)
  • v
    Is 
    Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits
    permessage-deflate and maxwindowbits supported?
  • v
    thatl save a ton of bandwith for repeated messages
1...575859...567Latest