availability of experimental mixed mode in `new Miniflare()` or `unstable_startWorker`
With
--x-mixed-mode available in wrangler dev, is there an experimental option in the constructor of config object for miniflare/startWorker? So that we get mixed mode when running workers programatically?33 Replies
AFAICT you can pass it a mixedModeConnectionString, but you would have to generate it yourself
I was playing around with the generator for it which spat out a
URL by passing in the .config from startWorker(), but trying to fetch() on it just returned HTTP 400 you must pass in a bindingWhat if you generate the URL, then pass it into Miniflare?
cc:@Dario who is working on this
Hey ๐
yeah you can absoluately start miniflare with the mixedModeConnectionString, you just need to run startMixedModeSession and then take the mixedModeConnectionString and plumb it to the Miniflare constructor
it should be pretty straightforward, however I think we'll also need to have an API in startWorker to allow this ๐ค
it might just be startWorker doing everything for you, or maybe startWorker accepting a mixedModeConnectionString
both should be pretty easy to implement ๐ค
ignore the above, I checked with the team and forgot one aspect of mixed mode ๐
yeah it should already be possible ๐
yeah we'd only need a way to allow you to enable the experimental mixed mode there ๐ค
I can get something ready for you today ๐
@Victor Can I ask your use-case for this? Super curious
@Victor @DemosJarco | Sushidata if you want you can give the prerelease in this PR a try ๐ https://github.com/cloudflare/workers-sdk/pull/9480
GitHub
add
experimentalMixedMode dev option to unstable_startWorker by...Fixes https://jira.cfdata.org/browse/DEVX-1958
This PR adds an experimentalMixedMode dev option to unstable_startWorker so that developers
can programmatically start a mixed mode session using star...
Well there's 3 answers to that
- immediate answer - get access cache & deployed do/d1 access in raw node.js (long running docker instance that can't be deployed to cf)
- planned long term answer - Unify the gap between our non cf-infra and cf infra without needing to make a ton of proxy workers
- future long term answer answer - had some calls with prospective customers that want on prem solutions and exploring potential options for seeing how much can be ran locally but with certain access to live services
That's amazing. I'll try it out in a bit (after my meetings)
great! thanks! ๐
I've tested it and it should work nicely, please let me know if it doesn't so that I can address any issue you might encounter ๐
dev.auth?Can confirm it works too

yay! ๐ฅณ
thanks for confirming that it works ๐
I need to add tests in my PR and then it should hopefully be ready to merge soon ๐
meaning that the change will be soon (hopefully tomorrow?) be in the next wrangler beta release ๐
One thing I did notice is doing
patchConfig() with a new remote resource doesn't attach it
Another bug I found: binding to a remote workflow which is defined in another worker binding "USER_WORKFLOW" refers to a service "core:user:worker-name", but no such service is definedWoah that is a really interesting idea -- would you be down to chat about this sometime? I would love to document this. if you're up for it, you can find time on my calendar and we can chat: https://calendar.app.google/6p7MB5PyCLgHbXus5
Sure! I just put some time on your calendar for tomorrow
Perfect! Chat then ๐ Thanks so much!
thanks! acknowledged ๐
workflows are currently not supported, we're working on it ๐
I thought it was supported...
currently the bindings included in this are: services, kv_namespaces, r2_buckets, d1_databases, queues and workflowswrangler@4.16.0
GitHub
Release wrangler@4.16.0 ยท cloudflare/workers-sdk
Minor Changes
#9288 3b8f7f1 Thanks @petebacondarwin! - allow --name and --env args on wrangler deploy
Previously it was not possible to provide a Worker name as a command line argument at the sam...
@Victor would you actually be okay meeting next week, such as next tuesday? So sorry, something came up super last minute
Sure
oh... no sorry that's my bad, that changelog meant to convey that we've added the
remote: true flag for the bindings (which I belive is in place) but not that they work in mixed mode, sorry for the confusion ๐@Victor @DemosJarco | Sushidata I just tried using startWorker with patchConfig and that actually looks to work as intended for me
I've run a js script that calls startWorker and patchConfig with a worker that simply logs responses from the bindings and everything does seem to work as it should (see the attached screenshots)
Could you clarify what isn't working for you?



Same
Workflows is not currently supported at this time with remote bindings (despite
experimental_remote being present for it as part of the wrangler.json schema)
-# Versions of wrangler since my last post stopped it from crashing on startWorker() but will still crash on invoking and binding functionDurableObjects in general are not, but is there a way to communicate with them via Worker binding?
https://developers.cloudflare.com/workers/development-testing/#using-remote-resources-with-durable-objects-and-workflows
if so, how?
I'm just trying to export data out of my SQLite DO
Directly/built-in cloudflare, there isn't. The only option would be to stand up a live deployed worker (put it behind ZT access or whatever other type of auth meets your needs) that is connected to it, and have it export the values
For DO SQL, I created my own variant of their D1 rest endpoint, (hono on a worker that has the DO binding) so I can run queries outside of DO binding anywhere
Wow! I'd love to see it!
Cloudflare Zero Trust
https://developers.cloudflare.com/cloudflare-one/applications/configure-apps/self-hosted-public-app/ You can make a "self-hosted public application" and put the domain of the created worker and the endpoint of the application
Sounds super cool, i'm very new to it! But i'll try it out
Thank you very much, would be amazing to see a sample repo with all of this to "chat with your DO SQLite"
Sorry, that code isn't open source and way too tightly intertwined to publish. But it's based on https://developers.cloudflare.com/api/resources/d1/subresources/database/methods/query/, but:
api endpoint:
- instead of
DATABASE_ID in the url, it's the doid 64 character hex
worker:
- internally it connects to the do via the hex id in the url and runs sqlExec() rpc function in the DO itself
do:
- sqlExec() that takes { sql, params } from the worker api json body and runs it (calling this.ctx.storage.sql.exec(sql, ...params) inside this.ctx.storage.transaction()) and then runs .toArray() on the result, which it just passes up the chain until it dumps it as json output.
- Gets some metadata from the ouput like .rowsRead, .rowsWritten, etc)
- Wrap in performance.now() to get timing metadata, but the value it gives sometimes isn't correct because of side channel timing mitigations (even though technically it should work because database works should count as I/O)
ZT is good if you want to keep it to internal access (scripted apps, other parts of your infra). But if you want to expose it to external users, you might want to stick to api key, jwt, etc insteadI see thank you