Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Miniflare – Local simulator for developing and testing Cloudflare Workers

github.com

Post reply on HN
Print view View original

21–30 of 30 posts

Re: Miniflare – Local simulator for developing and testing Cloudflare Workers

#21

Post by kentonv »

tiffanyh wrote: post #20
kentonv wrote: post #18

Earlier quoted context omitted.

> I think the hard limit CF imposes is of wall-clock time, not CPU time specifically. No, it's the other way around. The enforced limit is strictly on CPU time, not wall time. We use Linux's timer_create() with CLOCK_THREAD_CPUTIME_ID to set a timer that delivers a signal when a CPU time threshold is reached. The signal handler immediately terminates execution of JavaScript using V8's TerminateExecution() (which only…

> "Cloudflare Workers runs many guest isolates in a single process, therefore we cannot simply kill the process when one guest misbehaves. So, we have to do everything very differently from what a container host would do." Does this imply that another guest Worker can impact/takedown my Worker due to their tasks misbehaving?

> Does this imply that another guest Worker can impact/takedown my Worker due to their tasks misbehaving?

No, the system is designed to prevent that. Each guest runs in its own V8 isolate which we carefully control to prevent interference.

(Of course, all software has bugs from time to time. But we consider it a security flaw if one worker can somehow disrupt other workers, and handle it accordingly.)

Re: Miniflare – Local simulator for developing and testing Cloudflare Workers

#22

Post by tiffanyh »

kentonv wrote: post #21
tiffanyh wrote: post #20

Earlier quoted context omitted.

> "Cloudflare Workers runs many guest isolates in a single process, therefore we cannot simply kill the process when one guest misbehaves. So, we have to do everything very differently from what a container host would do." Does this imply that another guest Worker can impact/takedown my Worker due to their tasks misbehaving?

> Does this imply that another guest Worker can impact/takedown my Worker due to their tasks misbehaving? No, the system is designed to prevent that. Each guest runs in its own V8 isolate which we carefully control to prevent interference. (Of course, all software has bugs from time to time. But we consider it a security flaw if one worker can somehow disrupt other workers, and handle it accordingly.)

Awesome. Thanks so much.

Any considersation to expanding the Worker use case to allow for more deployment of full-blown web apps to the edge?

Re: Miniflare – Local simulator for developing and testing Cloudflare Workers

#23

Post by kentonv »

tiffanyh wrote: post #22
kentonv wrote: post #21

Earlier quoted context omitted.

> Does this imply that another guest Worker can impact/takedown my Worker due to their tasks misbehaving? No, the system is designed to prevent that. Each guest runs in its own V8 isolate which we carefully control to prevent interference. (Of course, all software has bugs from time to time. But we consider it a security flaw if one worker can somehow disrupt other workers, and handle it accordingly.)

Awesome. Thanks so much. Any considersation to expanding the Worker use case to allow for more deployment of full-blown web apps to the edge?

Of course! Many people are deploying full-blown web apps on Workers today. We're constantly working on new features to fill in gaps so more types of apps can be built entirely on Workers. Durable Objects, cron triggers, increasing the time limit from 50ms to 30 seconds (and eventually 15 minutes), etc. are all part of this, and we have more coming.

Re: Miniflare – Local simulator for developing and testing Cloudflare Workers

#24

Post by tiffanyh »

kentonv wrote: post #23
tiffanyh wrote: post #22

Earlier quoted context omitted.

Awesome. Thanks so much. Any considersation to expanding the Worker use case to allow for more deployment of full-blown web apps to the edge?

Of course! Many people are deploying full-blown web apps on Workers today. We're constantly working on new features to fill in gaps so more types of apps can be built entirely on Workers. Durable Objects, cron triggers, increasing the time limit from 50ms to 30 seconds (and eventually 15 minutes), etc. are all part of this, and we have more coming.

Any talk of a SQL database offering? The KV is awesome but there are times when a relational database is a way better fit.

E.g. I'd love to be able to deploy a full blown Elixir/Phoenix/Postgres app to Cloudflare Workers.

Re: Miniflare – Local simulator for developing and testing Cloudflare Workers

#25

Post by leros »

tiffanyh wrote: post #16

Question: how are people using Workers today? I'd love a service where I can push my {INSERT_YOUR_FAVORITE_WEBAPP_FRAMEWORK} to the edge and not have to manage the OS and Database. Is that what fly.io is building?

I use it to personalize content that should be in a CDN cache but can't because it's personalized.

I have application configurations that need to load super fast as they block application rendering. The magic of the configuration is they can be modified by rules based on the user loading the app, so I pull the configuration out of Cloudflare KV Store, tweak it a bit for the user, and return it.

Re: Miniflare – Local simulator for developing and testing Cloudflare Workers

#26

Post by elithrar »

jasongill wrote: post #7

Nice - I love Cloudflare Workers but hate that debugging eventually breaks down to a lot of copy & paste and editing in their lackluster "IDE". Was this built by someone at Cloudflare? If not, I hope they work there very soon and can turn this into a part of the Workers ecosystem

Have you used `wrangler dev`[1], their CLI-based workflow? I don’t need to use the web editor at all - I use my preferred editor and use wrangler to trigger builds + `wrangler tail` to get a stream of logs.

The linked project (miniflare) is effectively an local emulator, but Cloudflare does provide a solid “hybrid” local-remote workflow, even if not perfect.

[1]: https://blog.cloudflare.com/announcing-wrangler-dev-the-edge...

Re: Miniflare – Local simulator for developing and testing Cloudflare Workers

#27

Post by mikehostetler »

tiffanyh wrote: post #19
mikehostetler wrote: post #11

If you're stuck with Cloudflare, this makes sense. I've tried CF workers and don't like them because they are not developer friendly. I prefer https://fly.io - their dev experience is 10x better.

Would you mind expanding on how fly.io dev experience is better. See my similarly related question in this thread below. https://news.ycombinator.com/item?id=27750950

Sure

- Mature CLI tool, easy to build into CI and/or API with JSON responses - Docker based, so I can easily test my apps locally - Well designed secrets management - Well designed private networking if I need to log into running apps in any region

There are probably more, but those are the big ones I see from using Fly regularly

Re: Miniflare – Local simulator for developing and testing Cloudflare Workers

#28

Post by elithrar »

mikehostetler wrote: post #11

If you're stuck with Cloudflare, this makes sense. I've tried CF workers and don't like them because they are not developer friendly. I prefer https://fly.io - their dev experience is 10x better.

> I prefer https://fly.io - their dev experience is 10x better.

I really like Fly, but it’s not a straight comparison - Fly is a way to run OCI (“Docker”) images in a handful of locations across the world, with some helpful magicks to route users to the closest instance (provided you run them). Thus, the dev experience is… you’re building and running a container locally, just as you would in Cloud Run, Heroku or other services that run containers for you. That familiarity is nice (and certainly an intentional choice by Fly) but it’s hard to say it’s “theirs”.

Workers runs everywhere, simultaneously: all 200+ of their edge locations. They’re designed to be lightweight enough and don’t need “you” to scale them, or pick regions to deploy them into, but the trade-off is that the API & development workflow are more bespoke (a JS-based Service Worker like API). If I want to deploy something that can be as close to end-users as possible, or that can personalize responses from my origin or cache on-the-fly, I reach to Workers first.

Re: Miniflare – Local simulator for developing and testing Cloudflare Workers

#29

Post by lucacasonato »

rad_gruchalski wrote: post #10
jFriedensreich wrote: post #8

its a welcome addition to the cf worker ecosystem especially because of the features that are missing in most alternatives. however deno would lend itself much better to running cf workers locally and also i feel after the 4th cf workers testing environment it would be time to focus not on "simulation" or local testing but to start projects with the goal of being a compatible production ready implementation. such a p…

> however deno would lend itself much better to running cf workers locally What would be the reason for this?

Unlike Node, Deno has fetch and a web API based HTTP server built in.

Re: Miniflare – Local simulator for developing and testing Cloudflare Workers

#30

Post by jFriedensreich »

rad_gruchalski wrote: post #10
jFriedensreich wrote: post #8

its a welcome addition to the cf worker ecosystem especially because of the features that are missing in most alternatives. however deno would lend itself much better to running cf workers locally and also i feel after the 4th cf workers testing environment it would be time to focus not on "simulation" or local testing but to start projects with the goal of being a compatible production ready implementation. such a p…

> however deno would lend itself much better to running cf workers locally What would be the reason for this?

cf workers and deno both have a philosophy of web apis first where custom apis are mostly a last resort if the concept to be done does not exist in web apps or is out of scope. nodejs requires wrapper libraries like node-fetch etc. also deno and cf workers have both the idea to not share any access to host environments or siblings with js code and both use isolates to do this similar to chrome. nodejs usually shares the rights of the executing user.
Post reply on HN