Remote bindings likely simplifies the
Remote bindings likely simplifies the situation far more than attempting to accurately simulate everything locally or making developers pick between speed and precision.
The selective opt-in model stands out as especially clever.
Having the option “I want my D1 database calls to hit the real thing, but I’ll mock my KV store locally” is quite impressive.
Moreover, executing the actual workerd runtime while running locally ensures that you're getting actual Workers behavior for the execution environment, which is ideal. I'm interested in a couple of things:
Is there a measure to tell how much remote binding adds to the overhead? If I call a remote D1 database from my local Worker, will it be any slower than when operating in full --remote mode?
How do you manage remote resource credentials during local development? Is it the same as authorization used for wrangler dev --remote?
While developing against remote resources, do you have methods or known patterns to avoid contaminating production data by snapshotting/restoring state?
The below ideas feel like they are pointing me in the right direction. Rather than viewing the dichotomy between local and remote as the framing conflict, it may be better to take the opposite approach and consider what components need to be real vs. simulated for this particular session.
Since the launch of the feature, have you observed good adoption of remote bindings?
The selective opt-in model stands out as especially clever.
Having the option “I want my D1 database calls to hit the real thing, but I’ll mock my KV store locally” is quite impressive.
Moreover, executing the actual workerd runtime while running locally ensures that you're getting actual Workers behavior for the execution environment, which is ideal. I'm interested in a couple of things:
Is there a measure to tell how much remote binding adds to the overhead? If I call a remote D1 database from my local Worker, will it be any slower than when operating in full --remote mode?
How do you manage remote resource credentials during local development? Is it the same as authorization used for wrangler dev --remote?
While developing against remote resources, do you have methods or known patterns to avoid contaminating production data by snapshotting/restoring state?
The below ideas feel like they are pointing me in the right direction. Rather than viewing the dichotomy between local and remote as the framing conflict, it may be better to take the opposite approach and consider what components need to be real vs. simulated for this particular session.
Since the launch of the feature, have you observed good adoption of remote bindings?
6 Replies
Remote bindings likely simplifies the situation far more than attempting to accurately simulate everything locally or making developers pick between speed and precision. The selective opt-in model stands out as especially clever. Having the option “I want my D1 database calls to hit the real thing, but I’ll mock my KV store locally” is quite impressive. Moreover, executing the actual workerd runtime while running locally ensures that you're getting actual Workers behavior for the execution environment, which is ideal.Yes exactly! 😄 I'm happy you see if the same way we do 🫶
lot of questions! 😄 I'll do my best to answer them all
Either way, if you want please feel free to provide your feedback and ideas in this discussion: https://github.com/cloudflare/workers-sdk/discussions/9660 (and feel free to ping me directly if you want 🙂)
GitHub
Public Beta: Remote bindings in local development · cloudflare wor...
Hi all 👋 We’re excited to introduce beta support for remote bindings for local development, allowing you to connect to deployed resources like R2 buckets and D1 databases – all while running your W...
Since the launch of the feature, have you observed good adoption of remote bindings?oof... I can't find the numbers... 😓 but yeah we've checked the usage a few days ago and we were seeing a good adoption of remote bindings (like ~17% of
--remote)
(keeping in mind that it's still in beta 😄)
(unsurprisingly) very very much less then local bindings usages though
Is there a measure to tell how much remote binding adds to the overhead? If I call a remote D1 database from my local Worker, will it be any slower than when operating in full --remote mode?No, we haven't measured it (although that wouldn't be hard to do) Remote bindings use the same underlying stucture that
--remote does, so they should be virtually ideantical in terms of latency, there might be a few milliseconds of difference caused by the local logic we have to implement the proxying, but it really should be negligible 🙂
How do you manage remote resource credentials during local development? Is it the same as authorization used for wrangler dev --remote?Exactly the same yeah 🙂 (wrangler just requires your account id + api token)
While developing against remote resources, do you have methods or known patterns to avoid contaminating production data by snapshotting/restoring state?Nope, not at all (as far as I know) 🥲 If you have any suggestion/APIs we're all ears, this does sound like something that could be very useful to support! 😄
Thank you for taking your time answering all these I will review your answers and come back if I have any more questions suggestions
The below ideas feel like they are pointing me in the right direction. Rather than viewing the dichotomy between local and remote as the framing conflict, it may be better to take the opposite approach and consider what components need to be real vs. simulated for this particular session.mh.... I am not completely sure I follow the sentenct 😅 Basically you're saying that it you agree on the idea of not going local vs remote, but more for more flexible model when some behaviors are local and some are remote? 🙂 It's my pleasure, thanks so much for the interest! 😄 Yes, any time!
The state management thing is definitely interesting to think about. A few patterns that come to mind:
Database-level approaches:
Branching/preview environments - similar to how Vercel + PlanetScale work together, where each branch gets its own D1 database instance
Snapshot/restore APIs - like wrangler d1 snapshot create dev-session-123 and wrangler d1 restore dev-session-123
Transaction rollback mode - wrap dev sessions in a long-running transaction that auto-rollbacks on exit (though this might be tricky with D1's architecture)
Workflow-level approaches:
Dev environment isolation - wrangler dev --env=alice automatically creates/manages isolated resource instances
Seed data management - wrangler dev --seed=baseline that restores known good state before starting
@Dario