🚀 Feature Request: Provide platform features as mock module?

[leaysgur]

Describe the solution

Hi, I am the author of the cfw-bindings-wrangler-bridge module.

This was originally implemented to use bindings like KV and D1 even for local development using vite dev commands with SvelteKit.
Since it uses wrangler dev, we can use values from the preview environment as well as locally, which is very useful, at least for me.

I feel like this is a common request as a Cloudflare user.
leaysgur/cfw-bindings-wrangler-bridge#13

Other than that, it can also be used to go beyond the current service binding constraints in DX.

#1182

Now to the main topic, I recently found a next-on-pages project that is trying to do something similar.

cloudflare/next-on-pages#271

I wrote this issue because I wondered if the wrangler itself could provide a something similar feature.

Of course, there are many concerns, feasibility issues, etc... but, what do you think?

[penalosa]

Could you clarify the specific feature that would be helpful? I think Miniflare's getBinding's feature should address most of this, but happy to re-open if there's more that would be helpful from Wrangler here! cc @dario-piotrowicz

[dario-piotrowicz]

Thanks for the issue @leaysgur 🙂 , the idea sounds intriguing but wrangler doesn't really feel the best place to have some sort of proxy like that (if that's what you were suggesting), actually as @penalosa alluded baking in miniflare in devservers and provide an in-process bindings strategy (like the next-on-pages one you mentioned) sounds like a better alternative instead of having to force users to run two different processes and proxy one to the other (potentially introducing new APIs for accessing bindings).

We know that the current dev server situation is not optimal and we're trying hard to improve it, hopefully we'll soon find a solution that can be generally used in most dev servers without the need to run extra processes or other such complications.

For example one thing that would be very existing would be if we could actually have vite support the workerd runtime natively, that would allow dev servers to just get bindings without the need of any proxying 🙂 (like mentioned in this issue)

[leaysgur]

Thanks for your response.

I'll leave some notes in the hope that a better solution can be found soon.

• miniflare (+ workerd) does not provide full emulation at the moment
  • [Miniflare] Vectorize binding is not supported yet #4360
• I know that DX is better to be completed in one process, but that would require support for each environment
  • Even if we could support Vite, we might have to support Rspack separately next?
• Would it be better to have it as a runtime itself, like Bun, rather than implementing as a Vite plugin?
• Nice to have local + remote bindings combo
  • RFC: Multi-worker development #1182

And the need to mock the environment locally and the need to use remote data may be two different things.

[dario-piotrowicz]

Thanks for the comment @leaysgur 🙂 (sorry I only now noticed your comment), duly noted, thanks for the feedback I'll bring it back to the team

Regarding your points:

• miniflare (+ workerd) does not provide full emulation at the moment
  • [Miniflare] Vectorize binding is not supported yet #4360

I don't think thatminiflare (+ workerd) not providing a full emulation is something that should stop us, on the contrary I think that's even more of an incentive to keep miniflare up to date (instead of assuming it as a sub-par experience), but yeah something like this could potentially be overcome with remote support 🤔

• I know that DX is better to be completed in one process, but that would require support for each environment
  • Even if we could support Vite, we might have to support Rspack separately next?

Yes having a single process might not be the simplest thing, but it is usually what people expect nowadays as a good DX so I would really try to go for something like that, that being said, if that becomes a blocker having to run multiple processes can also be feasible (but not an optimal DX in my opinion)

Regarding Vite, I was mentioning that (and that's been a focus for the team as well) since it is so prevalent nowadays and most frameworks seem to run on top of it, so having a Vite solution would basically cover a large amount of use cases, yes, not totally ideal and not a solution for everything, but something that could really help a large number of developers 🙂

• Would it be better to have it as a runtime itself, like Bun, rather than implementing as a Vite plugin?

workerd is already a full runtime in which we can run our code, the biggest issue is that modern dev servers (I'm mainly thinking of Vite 😅) can't run in workerd as they heavily rely on nodejs APIs. We could try to build our own dev server/ecosystem and have something very Cloudflare specific, the issue is that even if we get something good up and running, if it is not going to be easily adaptable to existing frameworks then it might not really provide tangible benefits to users 😕

• Nice to have local + remote bindings combo
  • RFC: Multi-worker development #1182

Yes 🤔, I would assume that we could define a local only solution and then people could still use wrangler to run previews and get access to remove bindings, but I think you're suggesting that that wouldn't be good enough? and that having the ability to quickly iterate over remote data is very useful?

[leaysgur]

sorry I only now noticed

Don't worry about it. 😉 I very much appreciate your thoughtful reply!

I think that's even more of an incentive to keep miniflare up to date

I think that's right, too.

So when Vectorize was announced, I was rather surprised that there was no miniflare support. (I don't know if it was a matter of implementation difficulty or just an organisational issue or ...)

having a Vite solution would basically cover a large amount of use cases,

Agreed.
Just being able to handle locally closed mocks with a natural API in local development would be great!

I'm also watching with interest the movement towards this.

I think you're suggesting that that wouldn't be good enough?

Yes.

It is fine if you just want to preview, but as soon as you want to debug, it becomes a lot more difficult.

Currently, this can be achieved with wrangler pages dev + vite build --watch, but this takes too long to reload. 🥱

This was the original reason I developed my module in the first place.

Therefore,

• Want to debug code quickly locally using production data that is difficult to reproduce or prepare
• I want to edit production data more flexibly than with the REST API or the wrangler command

These were my motivations for wanting remote data.