[HN Gopher] Miniflare - Simulator for developing and testing Clo...
___________________________________________________________________
Miniflare - Simulator for developing and testing Cloudflare Workers
Author : madmax108
Score : 109 points
Date : 2021-09-24 10:30 UTC (12 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| pier25 wrote:
| This is great because quite frankly wrangler dev is just
| terrible.
|
| I've had nothing but problems with it.
| greyivy wrote:
| No kidding. Wrangler was so bad I stopped using Workers
| altogether.
| pier25 wrote:
| Same... I'm only using Workers for a very specific use case
| but otherwise I just prefer developing for any other
| serverless platform.
|
| Workers are great once they are deployed, but the DX is
| abismal...
| threepointone wrote:
| That bad, huh :( But I hear you. I'm working on making this
| better right now, I'd be happy to hear any complaints you
| have, and I hope we can get you back.
| greyivy wrote:
| I'd love to help but it's been so long that I don't
| remember what exactly it was I was struggling with. Thanks
| for the offer, though!
| thegagne wrote:
| It's gotten better. Wrangler tail works consistently now.
| threepointone wrote:
| Yeah, we recently made improvements so `wrangler tail`
| works without falling over, and we also show logs directly
| in the dashboard now
| (https://blog.cloudflare.com/introducing-workers-dashboard-
| lo...) More improvements coming, I promise.
| threepointone wrote:
| Hi there! I'm on the team, and we're going to invest a bunch of
| time and effort on making this experience _much_ better. Happy
| to hear any specific feedback if you 'd like, and I'll
| prioritise it. Feel free to reply here, or DM me on twitter
| @threepointone.
|
| Stay tuned, things should get better soon.
| pier25 wrote:
| For example, wrangler dev just stopped working on all my
| current workers. All requests return a timeout error.
|
| Only workers created with wrangler generate work.
|
| I opened this issue and never received an answer:
|
| https://github.com/cloudflare/wrangler/issues/2077
|
| I closed it because wrangler dev still works with generate,
| so I assumed it was a problem on my end.
|
| It still sucks that it just stopped working for no reason.
| threepointone wrote:
| That sounds like a terrible experience. I've reopened your
| issue and assigned it to myself, will investigate it soon.
| pier25 wrote:
| Thanks!
| kjksf wrote:
| Here are things I ran into.
|
| `wrangler login` doesn't work if I'm not already logged in to
| CloudFlare website. If I have to login first, it doesn't do
| whatever necessary redirect it should do so most of the time
| I have to run `wrangler login` twice.
|
| `wrangler dev` is slow.
|
| `wrangler dev` requires root domain.
| https://github.com/cloudflare/wrangler/issues/1529
|
| I also feel that the interaction between DNS settings and
| workers is under-documented, probably because it crosses
| responsibility of two different teams.
|
| For example, it took me way too long to figure out that if I
| have a workers-only website for foo.bar.org, I have to put
| dummy DNS entry for foo.bar.org
|
| Frankly, despite reading wrangler docs multiple times, I
| don't think I fully understand the interactions between
| what's in the DNS, what's in the workers route and further
| more if you add pages to the mix.
|
| Docs should explicitly spell out DNS / routes setup for most
| common scenarios like: 1) workers-only site (no proxying to
| any other server) 2) workers in front of a proxied website
|
| Workers should be seamlessly integrated with pages i.e. pages
| should just automatically recognize and use workers-site/
| directory on deploy.
|
| I don't think setting up pages automatically configures DNS
| settings for its domain, which it obviously should (might be
| mis-remembering).
| threepointone wrote:
| Great feedback! Some quick replies -
|
| - > `wrangler login` doesn't work if I'm not already logged
| in to CloudFlare website This should be fixed in our last
| release!
|
| - `wrangler dev` is slow. Agreed. We're working on making
| it faster, but miniflare is a great option for the fastest
| dev experience at the moment.
|
| - Regarding DNS/domains/Workers, this is all great
| feedback. We should be making this more painless/intuitive.
| We'll work on it!
| squaresmile wrote:
| - [Not relevant] There's this limitation about fetching
| host+port [0] in the worker. It works fine in wrangler dev
| but doesn't work on Cloudflare worker. I don't mind that it's
| a limitation of the platform but there should be
| documentation and wranlger dev should be consistent with the
| actual worker.
|
| - It's not relevant now but I couldn't figure out how to
| connect cloudflared with wrangler tail on windows. Wrangler
| tail points to the cloudflared docs but the cloudflared docs
| doesn't mention wrangler at all. I was pretty lost for what
| to do.
|
| - [Not relevant] I haven't investigated this properly but
| Promise.then.catch doesn't seem to work? async/await works
| though.
|
| - I'm pretty sure URL.createObjectURL in this example [1]
| doesn't work on the worker.
|
| - Wrangler dev doesn't have the request.cf object. I see why
| but a dummy one would be cool.
|
| None is deal-breaker but they wear you down when you walk
| through the documentation.
|
| [0] https://community.cloudflare.com/t/fetch-in-worker-
| strips-po...
|
| [1] https://developers.cloudflare.com/workers/examples/read-
| post
| threepointone wrote:
| This is amazing feedback, thank you very much! I'm going to
| work on each of these; but quickly - we definitely
| shouldn't have something that works in `wrangler dev` but
| not in the platform, and we should warn/error on that, our
| docs shouldn't have examples that don't work :facepalm:,
| and we should be spec compliant where we can. Thank you so
| much!
| kentonv wrote:
| Hi squaresmile,
|
| Thanks for the feedback!
|
| It sounds like you may be thinking of `wrangler preview`,
| not `wrangler dev`. `wrangler preview` runs the worker on a
| service that operates outside Cloudflare infrastructure, so
| a lot of things aren't realistic, like support for
| host+port and request.cf. `wrangler dev` runs the worker
| inside the real Cloudflare stack on the real edge, which
| should solve those problems. Our plan is to sunset
| `wrangler preview` in favor of `wrangler dev`.
|
| > It's not relevant now but I couldn't figure out how to
| connect cloudflared with wrangler tail on windows.
|
| Good news, this has been fixed recently -- `wrangler tail`
| no longer requires `cloudflared`.
|
| > - I haven't investigated this properly but
| Promise.then.catch doesn't seem to work? async/await works
| though.
|
| Promises are implemented inside V8, so they should work
| exactly the same on Workers as in Chrome and Node. I'd love
| to see an example of what's not working if you have one.
|
| > - I'm pretty sure URL.createObjectURL in this example [1]
| doesn't work on the worker.
|
| This is indeed an API we don't support, and realistically
| we probably can't support. I'd be interested to understand
| your use case for this.
| squaresmile wrote:
| > dev/preview
|
| Ah sorry, I was confusing stuffs. It wasn't even wrangler
| preview, it was the web editor on the worker website.
|
| > cloudflared
|
| Yep, I noticed that update. I couldn't have updated
| wrangler faster.
|
| > Promise.then
|
| I'm sorry again. False alarm. It's me not understanding
| when things get executed.
|
| > URL.createObjectURL
|
| I don't really have a use case for it. It was mostly me
| seeing the example code being reasonable, copied it and
| was surprised it didn't work.
| threepointone wrote:
| We should definitely not have examples on the docs that
| don't actually work. I'll fix this.
| pier25 wrote:
| Do you accept PRs on the docs (at least for the
| examples)?
| protoduction wrote:
| What I constantly ran into was disconnecting from the server
| I was connected to and wrangler not being able to handle
| that. At the time I had a somewhat spotty connection (nothing
| terrible), but it made wrangler dev very painful - so much so
| that I ended up writing my own node.js wrapper around it for
| local development. The lock-in to webpack also isn't great
| when I am nowadays accustomed to esbuild which is so much
| faster.
|
| Happy to see miniflare now :)
| threepointone wrote:
| Ohhh I remember this too, I hated how it consistently
| dropped connections. A community member fixed this for us
| (here https://github.com/cloudflare/wrangler/pull/2008) so
| that it transparently and automatically reconnects now and
| the experience has gotten so much better.
|
| And of course, miniflare reduces even the chance of that to
| zero :)
| threepointone wrote:
| We also don't have a lockin to webpack anymore (you can
| choose custom builds with the "javascript" type, which I
| admit is a little confusing). We're going to move away from
| even this dependency and make everything much faster and
| lighter, stay tuned.
| yewenjie wrote:
| Making the esbuild based starter the default one in the
| docs will be much more helpful.
| threepointone wrote:
| Honestly, agreed. Lemme take this back to the team.
| eloff wrote:
| Yeah, the esbuild experience is so much nicer.
| yewenjie wrote:
| Yes, seconded. Also local changes take a couple of seconds
| to reflect - which is sometimes really annoying for the dev
| experience.
| threepointone wrote:
| I've faced this too, where you'll save, then hit refresh,
| and it show the previous version; despite the fact that
| we "know" that the code is changed. SO we should be able
| to queue requests when we have a new version uploading
| (and of course, make the whole thing faster). Thanks for
| your feedback!
| dkersten wrote:
| I personally never really figured out how to get it working
| properly when I was using it. I resorted to just returning
| data as the response page to see what I was debugging and
| testing "in production". This was a few months ago, so I
| don't remember the details of what didn't work or why, just
| that I gave up on it altogether.
| threepointone wrote:
| I'm so sorry you had to deal with that. We're working on
| removing a lot of friction from the onboarding process, and
| making it easier to introspect what everything's doing.
| Thank you for your feedback!
| dkersten wrote:
| That's good to hear! I still use and like cloudflare
| workers, but at the time, earlier this year, the
| debugging experience was still a bit rough. So if that's
| improving, then I'm happy.
| ignoramous wrote:
| Will miniflare eventually find its way into wrangler and/or
| replace wrangler-dev?
| threepointone wrote:
| No specifics to share just yet, but we're definitely going
| to integrate wrangler more deeply with miniflare.
| k__ wrote:
| I use CFW with Pulumi, but it doesn't offer local dev.
| maxencecornet wrote:
| I find wrangler really decent to work with, it's pretty
| minimalist but does everything I need
|
| What kind of issues did you have ?
| jgrahamc wrote:
| What problems have you had?
| pier25 wrote:
| - Incomprehensible errors. Like you have a undefined var and
| the worker just breaks and doesn't tell you what's happening.
|
| - Terrible console.log() messages. I had to resort to using
| JSON.stringify for anything other than primitive values.
|
| - Timeout errors when using wrangler dev on workers that work
| perfectly when deployed.
|
| - Wrangler dev just crashing frequently or being super slow
| at reloading the worker.
| threepointone wrote:
| Errors - We're getting better at this. You can now use
| `--inspect` and use chrome devtools which should log proper
| exceptions (details to setup
| https://blog.cloudflare.com/profiling-your-workers-with-
| wran...) Console.logs - same as above! Real devtools,
| interactive and everything. Timeouts and crashes - This
| should be better now, timeouts and sessions expires now
| transparently heal and restart, so you shouldn't face
| errors (Please file an issue if you see different!)
|
| Overall we're working hard on making this experience
| better, please feel free to file issues if you see anything
| that's not expected. Thank you!
| jdcaron wrote:
| I'm very happy about this, an official support to run Workers
| locally. I invested some of my personal time to get this tool, I
| submitted a patch on a community project (since Cloudflare wasn't
| officially supporting this). I think it was a very important
| missing piece for me to consider Workers a serious development
| tool.
|
| https://github.com/gja/cloudflare-worker-local/commit/ce6004...
| jasongill wrote:
| Hooray, my dream came true:
| https://news.ycombinator.com/item?id=27748154
| asimpletune wrote:
| Wow, if I understand this correctly... this was posted on HN this
| morning, and by the afternoon it's already in the official
| cloudflare GH org?
|
| That reflects extremely well both on this repo as well as
| cloudflare.
| jorams wrote:
| It was first posted on HN 3 months ago[1], and moved to the
| cloudflare org a day ago[2].
|
| [1]: https://news.ycombinator.com/item?id=27736706
|
| [2]: https://twitter.com/_mrbbot/status/1441143456106094595
| threepointone wrote:
| Fun fact, that post 3 months ago was what got us folks at
| cloudflare in touch with the author, who then interned with
| us for 2 months (today was his last day!)
___________________________________________________________________
(page generated 2021-09-24 23:02 UTC)