Workerd: Open-source Cloudflare workers runtime(blog.cloudflare.com)
blog.cloudflare.com
Workerd: Open-source Cloudflare workers runtime
https://blog.cloudflare.com/workerd-open-source-workers-runtime/
137 comments
Thanks! Some notes on your notes:
1. We float a couple patches on V8 but we keep it very up-to-date. Generally by the time a version of V8 hits Chrome Stable, we're already using it. I would indeed like to upstream the patches, which should be easier now that everything is open.
2. FWIW the one protobuf file in the repo is from Jaeger, a third-party tracing framework. We actually aim to factor that out into something more generalized, which may eliminate the protobuf dependency. Workerd is very much based on Cap'n Proto for most things (and the Workers team does most of the maintenance of Cap'n Proto itself these days).
3. Yep, one of our main goals was to bake this into our `wrangler` CLI tooling to make local testing easier. I'd also like to ship distro packages once things are a bit more stable.
4. The code includes the ability to configure KV bindings, so you can run code based on Workers KV. But, the binding is a thin API wrapper over an HTTP GET/PUT protocol. You can in principle put whatever you want behind that, and we plan to provide an implementation that stores to disk soon. The actual Workers KV implementation wouldn't really be that interesting to release as it mostly just pushes data over to some commodity storage back-ends in a way that's specific to our network.
1. We float a couple patches on V8 but we keep it very up-to-date. Generally by the time a version of V8 hits Chrome Stable, we're already using it. I would indeed like to upstream the patches, which should be easier now that everything is open.
2. FWIW the one protobuf file in the repo is from Jaeger, a third-party tracing framework. We actually aim to factor that out into something more generalized, which may eliminate the protobuf dependency. Workerd is very much based on Cap'n Proto for most things (and the Workers team does most of the maintenance of Cap'n Proto itself these days).
3. Yep, one of our main goals was to bake this into our `wrangler` CLI tooling to make local testing easier. I'd also like to ship distro packages once things are a bit more stable.
4. The code includes the ability to configure KV bindings, so you can run code based on Workers KV. But, the binding is a thin API wrapper over an HTTP GET/PUT protocol. You can in principle put whatever you want behind that, and we plan to provide an implementation that stores to disk soon. The actual Workers KV implementation wouldn't really be that interesting to release as it mostly just pushes data over to some commodity storage back-ends in a way that's specific to our network.
Also on point 4: The next version of Miniflare -- our local testing environment -- is based on workerd and will include implementations of those HTTP APIs behind KV and R2 for testing purposes, which the Wrangler CLI tool will hook up automatically. (In fact maybe it already does, that team has been working so fast lately that I haven't been able to keep up...)
Is there an ETA on Miniflare v3? Ran into a problem recently using overlapping keys with forward slashes as they were not sanitized properly: https://github.com/cloudflare/miniflare/issues/167
`npx wrangler dev --experimental-local`!
> ...(and the Workers team does most of the maintenance of Cap'n Proto itself these days).
A team on workerd? I'm sure there is a lot of work involved in running the massive Workers platform, but curiously enough, the workerd git repo itself has relatively few commits from other engs... just where is the team? ;)
A team on workerd? I'm sure there is a lot of work involved in running the massive Workers platform, but curiously enough, the workerd git repo itself has relatively few commits from other engs... just where is the team? ;)
I had to squash history on the first commit for a bunch of reasons, but there are 55 co-authors listed. :)
https://github.com/cloudflare/workerd/commit/a265d5c22bf2a6b...
https://github.com/cloudflare/workerd/commit/a265d5c22bf2a6b...
(Meta: please don’t use indentation/preformatted text for lists; just make each list item a paragraph of its own. Even now they wrap, it’s still very disruptive, harder to read and feels more like a citation of some form, in this instance it took me a moment to decide this was your writing rather than something you were quoting.)
Just to clarify on point 4, directly from the link;
> Cloudflare is not providing any funding or making any funding decisions, and there is no guarantee that any particular company will receive funding through the program. All funding decisions will be made by the venture capital firms that participate in the program. Cloudflare is not a registered broker-dealer, investment adviser, or other similar intermediary.
So it’s not a fund. Cloudflare just has an agreement that a set of venture funds will set aside capital for companies that leverage workers and in return Cloudflare will provide deals / resources to said startups.
The reason I bring this up is because this is significantly less helpful to founders building on their platform than simply having a strategic fund of their own. The tl;dr on why is because it’s an additional hoop to jump through to get to an investment decision.
As a founder that has raised a significant amount of strategic capital and operates in the same space as CF Workers, if you want companies built on your platform funded, optimize for fast process. I worry the dealflow will actually work in the wrong direction here, with these firms simply telling startups, “we’ll give you some CF credits if you build stuff using workers — helps us hit our promised allocation with Cloudflare.” Which might be the intent, but running a strategic fund is probably more founder-friendly and may create better outcomes.
> Cloudflare is not providing any funding or making any funding decisions, and there is no guarantee that any particular company will receive funding through the program. All funding decisions will be made by the venture capital firms that participate in the program. Cloudflare is not a registered broker-dealer, investment adviser, or other similar intermediary.
So it’s not a fund. Cloudflare just has an agreement that a set of venture funds will set aside capital for companies that leverage workers and in return Cloudflare will provide deals / resources to said startups.
The reason I bring this up is because this is significantly less helpful to founders building on their platform than simply having a strategic fund of their own. The tl;dr on why is because it’s an additional hoop to jump through to get to an investment decision.
As a founder that has raised a significant amount of strategic capital and operates in the same space as CF Workers, if you want companies built on your platform funded, optimize for fast process. I worry the dealflow will actually work in the wrong direction here, with these firms simply telling startups, “we’ll give you some CF credits if you build stuff using workers — helps us hit our promised allocation with Cloudflare.” Which might be the intent, but running a strategic fund is probably more founder-friendly and may create better outcomes.
This is great. The Cloudflare model for Workers really deserves to become a de facto standard that can be pulled off the shelf for open source serverless functions. Really excited they’re opening this up this way. It seems like a great positive sum move.
> The Cloudflare model for Workers really deserves to become a de facto standard
Our small tech shop has been using Workers since Jan 2020. Leaving behind the monstrous and intimidating world of AWS, I simply couldn't contain my excitement, even back then. In the words of Eminem, Ease over these beats and be so breezy; Jesus, how can shit be so easy?!
Today, the entire platform around Workers is nothing short of astonishing. With Cloudflare's clout, Kenton and his team have utterly transformed serverless computing, staying true to the lessons-learnt from running sandstorm [0] way back when [1]!
It is almost comical (or diabolical, depending) that none of the Big3 have bothered competing with them. It is only the upstarts like Bun, Deno, SecondState, Kalix (Lightbend) and others that are keeping Cloudflare honest.
[0] https://news.ycombinator.com/item?id=20980278
[1] https://news.ycombinator.com/item?id=15364978
Our small tech shop has been using Workers since Jan 2020. Leaving behind the monstrous and intimidating world of AWS, I simply couldn't contain my excitement, even back then. In the words of Eminem, Ease over these beats and be so breezy; Jesus, how can shit be so easy?!
Today, the entire platform around Workers is nothing short of astonishing. With Cloudflare's clout, Kenton and his team have utterly transformed serverless computing, staying true to the lessons-learnt from running sandstorm [0] way back when [1]!
It is almost comical (or diabolical, depending) that none of the Big3 have bothered competing with them. It is only the upstarts like Bun, Deno, SecondState, Kalix (Lightbend) and others that are keeping Cloudflare honest.
[0] https://news.ycombinator.com/item?id=20980278
[1] https://news.ycombinator.com/item?id=15364978
I'm glad they opened this up, but I really hope "javascript first, every runtime should look like v8" doesn't become the standard here.
What part of the Cloudflare runtime looks v8 specific, rather than just (web) javascript specific?
I didn't mean to propose there should be a single standard. But for Javascript oriented FaaS, you really will have a hard time finding a better paradigm than the one they've settled on for Workers imo.
Agreed. Hopefully the WASM ecosystem continues developing and takes over.
It’s JavaScript first but the entire V8 dependency is abstracted behind an abstraction layer. Conceivably could be ported to other runtimes like Spidermonkey or JavaScriptCore with some work.
What do you (or others) see as its advantages relative to other similar offerings like those of AWS, GCP, Deno, Netlify, etc.?
The main advantage to me is the dedication to using standardized browser APIs. They have done a really good job of applying the Service Worker API to the problem of server side functions, and having the whole system be “MDN compatible” just makes everything more straightforward and leads to minimal surprises.
Cloudflare offers web standard javascript API's out of the box and is very fast as is
Workers are so damn good and easy…
I am originally from the PHP/Laravel world, recently had to quickly develop a very simple (5 endpoints) REST API and decided to give CF workers & KV storage a try. In an hour the API was running in production…
CF is really, really good at many things.
I am originally from the PHP/Laravel world, recently had to quickly develop a very simple (5 endpoints) REST API and decided to give CF workers & KV storage a try. In an hour the API was running in production…
CF is really, really good at many things.
one thing I've been curious about is since workerd is not a secure sandbox, what does Cloudflare use internally to make it secure?
AWS uses/maintains Firecracker which meets criteria to be considered secure but has a 300ms start. I've been confused how Cloudflare can sandbox things safely without the same cost
AWS uses/maintains Firecracker which meets criteria to be considered secure but has a 300ms start. I've been confused how Cloudflare can sandbox things safely without the same cost
The post links to this: https://blog.cloudflare.com/mitigating-spectre-and-other-sec...
so the answer is, a lot of things: * v8 isolates
* private processes for debugging/inspection
* "cordoned" V8 runtimes organized by level of trust (guards against V8 zero-days for one)
* linux namespacing as an outer sandbox layer, blocking fs and network access
* explicitly allowed capability-based security ...etc.
so the answer is, a lot of things: * v8 isolates
* private processes for debugging/inspection
* "cordoned" V8 runtimes organized by level of trust (guards against V8 zero-days for one)
* linux namespacing as an outer sandbox layer, blocking fs and network access
* explicitly allowed capability-based security ...etc.
This is awesome! Had been meaning to open-source parts of my startup [1] that is built almost entirely on Workers right now. Glad we can do that now without making massive changes to the code-base.
Amazed by what OP and the Workers team have done over the years. Took a while for us to get used to the Workers paradigm. But once we did, feature velocity has been great.
Last wish list item: a Postgres service on Workers (D2?) becoming available in the not too distant future
[1] https://datanarratives.com/
Amazed by what OP and the Workers team have done over the years. Took a while for us to get used to the Workers paradigm. But once we did, feature velocity has been great.
Last wish list item: a Postgres service on Workers (D2?) becoming available in the not too distant future
[1] https://datanarratives.com/
I went to use your product and connect Google Analytics to give it a shot, but you haven't verified the app w/ Google, so you get a big warning. I closed out of the browser. Might want to look into that.
Yikes, yes. Thank you for the heads up!
We've mostly been using the GA plugin for use with beta users. Had completely forgotten about the need to verify the app with Google. Will do that this week.
We've mostly been using the GA plugin for use with beta users. Had completely forgotten about the need to verify the app with Google. Will do that this week.
> a Postgres service on Workers (D2?)
Not sure where Cloudflare's with relational database connectors [0], but the next best thing is MySQL via Workers: https://news.ycombinator.com/item?id=32511577
[0] https://archive.is/Q18Gs
Not sure where Cloudflare's with relational database connectors [0], but the next best thing is MySQL via Workers: https://news.ycombinator.com/item?id=32511577
[0] https://archive.is/Q18Gs
They do have relational DB connectors [1], which have been working great for us. But maintaining a centralised DB is still a bit of a pain and latency can be high, depending on where users are accessing them from. Having a managed, distributed SQL service will be easier to manage and will likely have much lower latency. Their SQLite DB, D1 [2] looks interesting. But would be awesome to have Postgres' more complete feature set as a managed, low-latency service
[1] https://blog.cloudflare.com/relational-database-connectors/ [2] https://blog.cloudflare.com/whats-new-with-d1/
[1] https://blog.cloudflare.com/relational-database-connectors/ [2] https://blog.cloudflare.com/whats-new-with-d1/
The event nature seems like a light version of Erlang or Elixir without the power of those. Erlang and Elixir can run millions of light weight processes though vs 1000s. Still so many questions though like what is deployment like? Build something using just workers so we can see the power of it.
You might be interested in Durable Objects, which is essentially an actor model within Workers.
https://blog.cloudflare.com/introducing-workers-durable-obje...
Durable Objects aren't exactly the same as Erlang actors (which is why we don't usually call them "actors" -- we found it led to some confusion), but at some level it's a similar concept.
You can easily have millions of Durable Objects in a Workers-based application.
Currently workerd has partial support for Durable Objects -- they work but data is stored in-memory only (so... not actually "durable"). The storage we use in Cloudflare Workers couldn't easily be decoupled from our network, but we'll be adding an alternative storage implementation to workerd soon.
https://blog.cloudflare.com/introducing-workers-durable-obje...
Durable Objects aren't exactly the same as Erlang actors (which is why we don't usually call them "actors" -- we found it led to some confusion), but at some level it's a similar concept.
You can easily have millions of Durable Objects in a Workers-based application.
Currently workerd has partial support for Durable Objects -- they work but data is stored in-memory only (so... not actually "durable"). The storage we use in Cloudflare Workers couldn't easily be decoupled from our network, but we'll be adding an alternative storage implementation to workerd soon.
Durable Objects are incredible - I've been using them and they just make so much sense. I'm surprised none of the other cloud providers have ripped them off yet. Do you think they're too different to the usual app deployment patterns, and have either an operational or a conceptual barrier?
They remind me of this article: http://ithare.com/scaling-stateful-objects/
They remind me of this article: http://ithare.com/scaling-stateful-objects/
It's interesting to read about Durable Objects. It strikes me as conceptually very similar to what's called Virtual Actors, or Grains specifically in Microsoft Orleans, even if the underlying infrastructure is quite different. Seems like they struggled with naming as well.
One critical thing that I couldn't find info about is what reliability to expect from the persistent storage for a Durable Object. Is it more or less a write to a single disk without redundancy? If there's redundancy, to what degree? Essentially, how much would you need to build on your own in terms of replication for a production scenario if using Durable Objects as primary storage?
I get that they can use other, separate storage if necessary, but either way it seems like an important consideration when designing a system on top of them.
One critical thing that I couldn't find info about is what reliability to expect from the persistent storage for a Durable Object. Is it more or less a write to a single disk without redundancy? If there's redundancy, to what degree? Essentially, how much would you need to build on your own in terms of replication for a production scenario if using Durable Objects as primary storage?
I get that they can use other, separate storage if necessary, but either way it seems like an important consideration when designing a system on top of them.
Durable Object storage writes are not confirmed until they are on disk in three geographically separate datacenters. So, pretty reliable.
The fact that there is one unique instance of the object live at a time (and therefore only one client for the distributed storage) lets us do a lot of tricks to hide the storage latency.
https://blog.cloudflare.com/durable-objects-easy-fast-correc...
The fact that there is one unique instance of the object live at a time (and therefore only one client for the distributed storage) lets us do a lot of tricks to hide the storage latency.
https://blog.cloudflare.com/durable-objects-easy-fast-correc...
I looked in the docs and thought I searched well enough, but evidently not. That looks great, thanks a lot!
The actor model design pattern. Mostly obsolete today even if several cloud providers tries to get benefits from it.
Looks like a significant technical achievement.
However, I don't entirely get it. If every machine runs every service with library-like overhead for calls across them, how is that different from a monolith that links in libraries? It just seems more complex for no benefit.
However, I don't entirely get it. If every machine runs every service with library-like overhead for calls across them, how is that different from a monolith that links in libraries? It just seems more complex for no benefit.
Because each service runs in its own isolate, it can be built and deployed independently of the others. So if some other team's code is broken at HEAD, that doesn't stop your team from deploying. Also you don't have to agree with other teams about exactly what versions of dependencies you use, you can monkey-patch APIs without braking anyone else, etc. So, all the usual development workflow benefits of microservices, without the network overhead.
LD_PRELOAD is calling. There are advantages and disadvantages to this approach: shipping one single binary means that you don't have to worry about testing compatibility between versions of your microservices/libraries. We went through this with dynamic/static linking a long time ago. Static linking seems to have generally won.
[deleted]
Sure, I see.
I guess it's not a problem I've encountered so far. Perhaps I just haven't worked in a company big enough? Only on the scale of hundreds so far.
Branching, agreeing on interfaces and tests have been sufficient to allow linking, in my experience.
I guess it's not a problem I've encountered so far. Perhaps I just haven't worked in a company big enough? Only on the scale of hundreds so far.
Branching, agreeing on interfaces and tests have been sufficient to allow linking, in my experience.
We are curious about this set of solutions for allowing clients to run their own code on our system.
For example, a client wants to write a workflow but has a custom step that integrates with their system only. They can write the code and run as part of our workflow without us worrying about them writing something nefarious and breaking out of the sandbox.
That said, the workerd github says that this can't (yet?) be relied on to be a security sandbox.
For example, a client wants to write a workflow but has a custom step that integrates with their system only. They can write the code and run as part of our workflow without us worrying about them writing something nefarious and breaking out of the sandbox.
That said, the workerd github says that this can't (yet?) be relied on to be a security sandbox.
It depends on how much you trust your clients.
workerd ensures that a Worker cannot access protected resources by accident or negligent programming. What it can't protect against (on its own) is intentional exploitation of security bugs.
If your clients are people whom you've spoken to face-to-face and signed contracts with, then you can probably trust that they won't exploit a V8 zero-day to break the workerd sandbox, because if they did, it would clearly be a crime and you could prosecute them.
If your clients are random people who can sign up on the internet without talking to anybody, then they may be able to evade such identification and therefore prosecution. In that case you need a stronger sandbox to contain them.
workerd ensures that a Worker cannot access protected resources by accident or negligent programming. What it can't protect against (on its own) is intentional exploitation of security bugs.
If your clients are people whom you've spoken to face-to-face and signed contracts with, then you can probably trust that they won't exploit a V8 zero-day to break the workerd sandbox, because if they did, it would clearly be a crime and you could prosecute them.
If your clients are random people who can sign up on the internet without talking to anybody, then they may be able to evade such identification and therefore prosecution. In that case you need a stronger sandbox to contain them.
It’s people we talk to and have contracts with but the devs they might have working on it, lesser known quantity.
But still isn’t the Wild West.
It would likely be more of a “this person wrote crappy code that’s bringing down everyone else’s worker” or “this client wants to know if we have proper guards on their data”
But still isn’t the Wild West.
It would likely be more of a “this person wrote crappy code that’s bringing down everyone else’s worker” or “this client wants to know if we have proper guards on their data”
An isolate is a runtime thing, not a deployment thing.
A regular javascript module can be deployed independently. And have its own version of dependencies. I'm just not seeing what this really adds over existing widely available, well understood options.
I guess protection from other teams uncontrolled monkey-patching is something (I don't think there's probably any legitimate reason to monkey patch something yourself in normal production -- why wouldn't you patch or replace the problematic thing?), but there might be other ways to deal with that short of a new runtime environment.
I'm a little worried truly independent updating... imagine starting a request with one version of the auth module but finishing it with another. Not sure people really want to have to account for that. (Maybe that's accounted for, so maybe an unwarranted worry.)
A regular javascript module can be deployed independently. And have its own version of dependencies. I'm just not seeing what this really adds over existing widely available, well understood options.
I guess protection from other teams uncontrolled monkey-patching is something (I don't think there's probably any legitimate reason to monkey patch something yourself in normal production -- why wouldn't you patch or replace the problematic thing?), but there might be other ways to deal with that short of a new runtime environment.
I'm a little worried truly independent updating... imagine starting a request with one version of the auth module but finishing it with another. Not sure people really want to have to account for that. (Maybe that's accounted for, so maybe an unwarranted worry.)
What's the use-case for workers outside of CDN edge compute?
I understand why I'd want to do edge compute: it lets me shift work (in some cases at least) from my backend to the CDN, so my backend gets less traffic and users (possibly) get responses faster since the workers run on CDN edge nodes.
But obviously if I'm running workerd myself, I'm not doing edge compute (unless I'm also operating my own CDN). And if I'm not doing edge compute, just deploying code or a container to a server seems easier. Is it for the case where you want to do serverless stuff in a runtime you host yourself?
I understand why I'd want to do edge compute: it lets me shift work (in some cases at least) from my backend to the CDN, so my backend gets less traffic and users (possibly) get responses faster since the workers run on CDN edge nodes.
But obviously if I'm running workerd myself, I'm not doing edge compute (unless I'm also operating my own CDN). And if I'm not doing edge compute, just deploying code or a container to a server seems easier. Is it for the case where you want to do serverless stuff in a runtime you host yourself?
The blog post attempted to explain what makes workerd interesting as a platform, independent of Cloudflare. It allows for a new development model where you split your application into smaller components. Maybe that's interesting to you, maybe it isn't.
But the other reason you might develop on workerd is because you want the option to deploy to Cloudflare later. The advantage of Cloudflare isn't just that it's "edge" and therefore closer to clients -- it's also just a lot easier to deploy code on Workers a lot of the time than it is to manage servers on traditional cloud providers.
But the other reason you might develop on workerd is because you want the option to deploy to Cloudflare later. The advantage of Cloudflare isn't just that it's "edge" and therefore closer to clients -- it's also just a lot easier to deploy code on Workers a lot of the time than it is to manage servers on traditional cloud providers.
From development point of view, workerd would encourage this new nanoservices/lambda/function paradigm because it would be much easier to develop and test in self-hosted environment or even CI/CD pipeline.
The obvious one to me is migrating off of cloudflare...
And cloudflare making it easier to migrate away, also makes it easier to migrate to, since you aren't quite so stuck.
And cloudflare making it easier to migrate away, also makes it easier to migrate to, since you aren't quite so stuck.
Same code on premise as on edge.
Could be some things aren't allowed to run in the cloud for gdpr, privacy reasons or whatever
Could be some things aren't allowed to run in the cloud for gdpr, privacy reasons or whatever
Workers are a really nice, fast and awesome way to bend legacy APIs to new interfaces.
I fear that, every worker could end in spaghetti Code and nobody remembers why they used this or that and where it was saved.
You could follow the path of the request, but I see some delevopers going crazy with workers.
I use workers too, I love them.
I fear that, every worker could end in spaghetti Code and nobody remembers why they used this or that and where it was saved.
You could follow the path of the request, but I see some delevopers going crazy with workers.
I use workers too, I love them.
This is great, thank you for open-sourcing. One limitation is see with this model which is clearly stated in the post is that it is javascript/wasm and HTTP servers only. The deployable workers model is a great one and I had hoped to provide an adapter for the open-source windmill[1] project by transforming the normal scripts that are our units of execution into http servers runnable in workderd.
We support typescript (deno), go and python. Short of those languages becoming 100% transpilable to wasm, we will have to fallback to use firecracker or keep our current system implemented from scratch using nsjail for sandboxing and a fork for each process.
[1]: https://github.com/windmill-labs/windmill
We support typescript (deno), go and python. Short of those languages becoming 100% transpilable to wasm, we will have to fallback to use firecracker or keep our current system implemented from scratch using nsjail for sandboxing and a fork for each process.
[1]: https://github.com/windmill-labs/windmill
Regarding the HTTP limitation, we are working towards adding raw TCP and other protocols soon. (I know we've been saying this for a while... too much to do, too little time, and this one got reprioritized down the list a bit, but is getting close to the top again.)
But as far as JavaScript/Wasm, that's a pretty inherent design feature to the Workers architecture. Cloudflare will probably provide containers eventually but that'll likely present itself as more of an add-on than a core part of the platform.
The problem is, containers are just too heavy to support the nanoservices model as described in the blog post. JavaScript and Wasm are really the only viable options we have for something lighter-weight that meets our isolation needs. Other language VMs are generally not designed nor battle-tested for this sort of fine-grained isolation use case.
But as far as JavaScript/Wasm, that's a pretty inherent design feature to the Workers architecture. Cloudflare will probably provide containers eventually but that'll likely present itself as more of an add-on than a core part of the platform.
The problem is, containers are just too heavy to support the nanoservices model as described in the blog post. JavaScript and Wasm are really the only viable options we have for something lighter-weight that meets our isolation needs. Other language VMs are generally not designed nor battle-tested for this sort of fine-grained isolation use case.
Adding raw TCP is a big deal, it skips all the existing security stack that focuses on HTTP/S.
There is Spectrum and Transit to provide network level protection but... only a few can afford that.
Does this mean that TCP workers would be exposed to network level attacks or would it use transit/spectrum? If it turns out to be protected; I'd say there would be little to no reason to use Spectrum unless the pricing turns out to be atrocious for long lived connections (which is kind of the point of having TCP workers in the first place).
I hope I did not come out as rude; I'm genuinely curious about what's the plan behind all of this.
Edit: I pointed out there would be no use for spectrum since one could "easily" build a reverse proxy with a tcp worker.
Does this mean that TCP workers would be exposed to network level attacks or would it use transit/spectrum? If it turns out to be protected; I'd say there would be little to no reason to use Spectrum unless the pricing turns out to be atrocious for long lived connections (which is kind of the point of having TCP workers in the first place).
I hope I did not come out as rude; I'm genuinely curious about what's the plan behind all of this.
Edit: I pointed out there would be no use for spectrum since one could "easily" build a reverse proxy with a tcp worker.
The exact details aren't all nailed down but I'd expect for incoming connections Workers would integrate directly with Spectrum. I don't know what that might mean for pricing, but I imagine we'd find a solution where cost doesn't block people from building cool things.
Kudos to Kenton who keeps delivering great stuff on Workers.
Thank you! But for the record there are at least 56 people who contributed to this code and they all deserve credit. :)
https://github.com/cloudflare/workerd/commit/a265d5c22bf2a6b...
https://github.com/cloudflare/workerd/commit/a265d5c22bf2a6b...
Much respect for this response. Your tech work is obviously reputable but really wholesome to see humility and honesty on such cool big work.
I've been watching Workers with interest basically since the beginning. Now they just need to bring WebSockets support out of beta. Or is the long-term plan to replace raw WebSockets servers with something higher-level like the new Cloudflare Queues?
Hmm, I believe WebSocket support came out of beta at the same time as Durable Objects, about a year ago. It's entirely possible we forgot to update a doc, though.
We do have some plans around making WebSockets more efficient by allowing the application to shut down while keeping idle WebSockets open, and start back up on-demand when a message arrives.
We do have some plans around making WebSockets more efficient by allowing the application to shut down while keeping idle WebSockets open, and start back up on-demand when a message arrives.
> We do have some plans around making WebSockets more efficient by allowing the application to shut down while keeping idle WebSockets open, and start back up on-demand when a message arrives.
Please make noise when that rolls out! I was literally wishing for that yesterday.
I want to use Cloudflare Workers to quickly connect p2p WebRTC clients, but when a new peer joins there needs to be open WebSockets to send connection-setup messages to each peer in the room. But with how that works / is billed today it really doesn’t make sense to have a bunch of idling WebSockets.
An alternative is having each client poll the worker continuously to check for new messages, but that introduces a bunch of latency during the WebRTC connection negotiation process.
Please make noise when that rolls out! I was literally wishing for that yesterday.
I want to use Cloudflare Workers to quickly connect p2p WebRTC clients, but when a new peer joins there needs to be open WebSockets to send connection-setup messages to each peer in the room. But with how that works / is billed today it really doesn’t make sense to have a bunch of idling WebSockets.
An alternative is having each client poll the worker continuously to check for new messages, but that introduces a bunch of latency during the WebRTC connection negotiation process.
Instead of adding a non-standard API to opt-out of existing networking functionality, it would be great to see a lower-level networking primitive to unlock these kinds of use cases. I wrote more (with a proof-of-concept) here: https://readable.writable.stream
Fastly has something like this: https://docs.fanout.io/docs/http-streaming
See the top of this doc: https://developers.cloudflare.com/workers/learning/using-web...
Doh. Yeah that's way out-of-date, I'll get it fixed.
FWIW contrary to the note on that page, WebSocket pricing is documented along with Durable Objects here:
https://developers.cloudflare.com/workers/platform/pricing/#...
FWIW contrary to the note on that page, WebSocket pricing is documented along with Durable Objects here:
https://developers.cloudflare.com/workers/platform/pricing/#...
> A WebSocket being connected to the Durable Object counts as the Object being active.
> If 100 Durable Objects each had 100 WebSocket connections established to each of them which sent approximately one message a minute for a month, the estimated cost in a month would be, if the messages overlapped so that the Objects were actually active for half the month:
I remember looking at that page before and finding these two lines confusing. Based on the first line, it seems that the objects would be considered active for the entire month, whereas the second one raises the possibility that a websocket can be connected to a durable object without it being considered active.
> If 100 Durable Objects each had 100 WebSocket connections established to each of them which sent approximately one message a minute for a month, the estimated cost in a month would be, if the messages overlapped so that the Objects were actually active for half the month:
I remember looking at that page before and finding these two lines confusing. Based on the first line, it seems that the objects would be considered active for the entire month, whereas the second one raises the possibility that a websocket can be connected to a durable object without it being considered active.
Yeah that seems to be in conflict with this earlier passage:
> A WebSocket being connected to the Durable Object counts as the Object being active.
> A WebSocket being connected to the Durable Object counts as the Object being active.
Does the WebSockets protocol now have some kind of built-in keepalive/ping functionality? Something like that is practically necessary for any long-running idle connection on top of TCP. Without built-in keepalive, the application would have to stay running just to handle pings, right?
WebSockets has a protocol-level ping/pong interaction. If one wrote a WebSocket proxy, one could respond to pings on that level, without proxying them to a backend.
While the WebSocket protocol indeed has built-in ping/pong, it's somewhat difficult to rely upon. Web browsers do not provide any API to send pings from the client side. As a result a lot of applications end up implementing application-level pings.
In order to support efficient WebSocket idling, we probably need to have some ability to respond to application-level pings without actually executing JavaScript. TBH I'm not exactly sure how this will work yet.
In order to support efficient WebSocket idling, we probably need to have some ability to respond to application-level pings without actually executing JavaScript. TBH I'm not exactly sure how this will work yet.
You could make an incoming WebSocket message behave much like an incoming HTTP request: The DO worker starts running, reads the message, runs any `event.waitUntil` work to completion, and goes to sleep. Let your runtime unload DO workers while holding on to their WebSocket connections.
That would mean maintaining "chatroom" state in memory wouldn't be enough, the DO worker would have to always write it to the durable store, to be safe to unload.
You'd have some sort of a "WebSocket connection ID" that could be used as key for storing state, and when the next message comes in, the worker would use that key to fetch state.
EDIT: And the ability to "rejuvenate" other WebSocket connections from their IDs, so you can e.g. resend a chat room message to all subscribers.
That would mean maintaining "chatroom" state in memory wouldn't be enough, the DO worker would have to always write it to the durable store, to be safe to unload.
You'd have some sort of a "WebSocket connection ID" that could be used as key for storing state, and when the next message comes in, the worker would use that key to fetch state.
EDIT: And the ability to "rejuvenate" other WebSocket connections from their IDs, so you can e.g. resend a chat room message to all subscribers.
"We will open source it in near future"
Till now this was the biggest lie from many companies. I love Cloudflare and this is why!
Using Cap'n Proto instead of some bloat <3
Using Cap'n Proto instead of some bloat <3
What is the endgame here? Do I run all my backend stuff at some point as workers that are closer to the customer or do I mostly use it for server-side redering?
I am interested in knowing more about possible deployment options that workerd is going to offer. Any plans to cluster workerd nodes up to propagate code changes through a central orchestrator API? Or can we expect to have something like Krustlet on K8s but for workerd instead of wasmtime?
Good question. I don't think we have a clear answer yet. Ideally I think we want to be agnostic to these things as much as possible, so as to fit into whatever orchestration systems people are already using. At the same time, I personally have very little experience with k8s so it's hard for me to say what will work well there.
Abstractly speaking, I expect we need to build some workflow tooling around the nanoservices concept, since somehow all your teams' nanoservices eventually need to land on one machine where one workerd instance loads them all. But should we do that by updating whole container images, or distributing nanoservice updates to existing containers, or...?
This would be a great discussion topic for the "discussions" tab in GitHub. :)
Abstractly speaking, I expect we need to build some workflow tooling around the nanoservices concept, since somehow all your teams' nanoservices eventually need to land on one machine where one workerd instance loads them all. But should we do that by updating whole container images, or distributing nanoservice updates to existing containers, or...?
This would be a great discussion topic for the "discussions" tab in GitHub. :)
> When Workers launched five years ago, it was unusual for a non-browser to offer web APIs, but we are pleased to see that the broader JavaScript ecosystem is now converging on them.
Can anyone give some examples of this? I’m not sure I’m following exactly here. Is this referring to isomorphic (JS) API’s?
[edit:typo]
Can anyone give some examples of this? I’m not sure I’m following exactly here. Is this referring to isomorphic (JS) API’s?
[edit:typo]
I believe they're referring to environments like Deno just using say, the fetch api from the browser, as their standard http client interface. Same code just works wherever, engineer that knows how to do it one place, knows how to do it another, etc...
A Community Group for Web-interoperable JavaScript runtimes (May 2022), https://archive.is/JIzMK.
> workerd is not just another way to run JavaScript and Wasm. Our runtime is uniquely designed in a number of ways.
How many non-javascript folks use this? What's better than using fly.io?
How many non-javascript folks use this? What's better than using fly.io?
I don't know any JavaScript but i use workers for discord bots written in rust (and compiled to wasm).
it's sad that they didn't go the same way than fastly which actually use a wasm runtime even for javascript by compiling spidermonkey to wasm: https://github.com/fastly/js-compute-runtime
I think thats way more clever than having a mixed runtime.
and they use wizer to make it more performant.
It’s a clever technique no doubt. In practice for JS-centric workloads (which we’ve found is the bulk of demand), using V8 is still much much more efficient, has faster performance than Wizer’s approach and easier to scale out (the scale that Workers runs at can boggle the mind).
We are trying to figure out how to move more of the API parts of runtime to something not c++ without significantly negatively impacting memory / CPU (safety, correctness, speed of development, etc). It’s an interesting problem to try to do at Cloudflare scale.
We are trying to figure out how to move more of the API parts of runtime to something not c++ without significantly negatively impacting memory / CPU (safety, correctness, speed of development, etc). It’s an interesting problem to try to do at Cloudflare scale.
thanks for the info, well yeah wizer still does not make it as fast as c++ v8
The Fastly approach has some advantages for wasm, but Cloudflare have mentioned that the vast majority of their users want JavaScript and TypeScript. Cloudflare's approach is more optimized for that: running a JS VM directly will take a lot less overhead than one compiled to wasm atm (since JS VMs depend heavily on JITing, and compiled JS VMs will have a much larger memory footprint due to the bundled compiled runtime).
It's possible that Cloudflare and Fastly users are different enough that different approaches make sense.
It's possible that Cloudflare and Fastly users are different enough that different approaches make sense.
Can you dynamically push/deploy things to running daemon or you always have to explicitly specify it up front, before booting, in cap’n proto config?
At present you have to reload the process after changes, but the underlying codebase obviously supports dynamic loading so this may change. Today is about getting the code out there, the next step is figuring out exactly what workflows people want to use this with. Please feel free to post under the discussions tab of the GitHub repo if you have ideas!
[deleted]
What does this mean for miniflare?
Currently there is no way to test for cloudflare-esque failures. For instance, what does my worker do when the kv lookup fails or another cloudflare infrastructure related promise isn't fulfilled? I think actually running the true worker runtime in a testing environment is key.
Currently there is no way to test for cloudflare-esque failures. For instance, what does my worker do when the kv lookup fails or another cloudflare infrastructure related promise isn't fulfilled? I think actually running the true worker runtime in a testing environment is key.
Hey congrats on the release! This is a big step and really helps build some trust in the platform.
this appears very much like actor based concurrency/isolation model.
why ?
That’s probably the first codebase I have seen in years where someone picked .c++ as file extension.
(In my opinion objectively the worst possible choice because + requires URL encoding ;))
(In my opinion objectively the worst possible choice because + requires URL encoding ;))
Haha, I started doing this with Cap'n Proto 10 years ago. :)
I periodically get crap for it but so far it hasn't really broken anything.
The biggest annoyance is exactly what you point out -- the GitHub URLs look ugly because they %-encode the plus signs. Though it turns out you can manually un-encode them and it works fine.
I periodically get crap for it but so far it hasn't really broken anything.
The biggest annoyance is exactly what you point out -- the GitHub URLs look ugly because they %-encode the plus signs. Though it turns out you can manually un-encode them and it works fine.
It breaks Make, which does not have a default rule for “*.c++” files, but does have rules both for “*.cpp” files and the older naming custom of “*.C” files.
In modern GNU make it is generally advised to disable default rules anyways. I know some people try to do portable Make, but I am pretty over that idea myself, so if I do use Make, I'm using GNU extensions and GNUmakefile.
GNU Make does not have a rule for “*.c++” files, either.
Do you have a reference to the advice to disable default rules? It sounds counterproductive to me.
Do you have a reference to the advice to disable default rules? It sounds counterproductive to me.
There's lots of different opinions on how to use Make, but here's one. https://tech.davis-hansson.com/p/make/
Not very well recieved here on HN a month ago: https://news.ycombinator.com/item?id=32541016
That's a sign that it's good :)
Jokes aside though, the only major complaint people have is about .RECIPEPREFIX, which I also don't follow. I didn't read too many comments, but the top voted comments do not appear to take issue with the advice to disable built-in rules.
I'd be surprised, since it is far from the first time I've heard that advice, and it never seemed very controversial.
Jokes aside though, the only major complaint people have is about .RECIPEPREFIX, which I also don't follow. I didn't read too many comments, but the top voted comments do not appear to take issue with the advice to disable built-in rules.
I'd be surprised, since it is far from the first time I've heard that advice, and it never seemed very controversial.
Why would you use .c++ instead of the standard .cpp?
I got tired of arguing about .cpp vs. .cc vs. .cxx vs. .C.
So I used the actual name of the language, and it worked fine. :)
So I used the actual name of the language, and it worked fine. :)
Oh, there's worse; you can use emoji in filenames.
[deleted]
Anything other than null and `\` are valid on linux iirc
You mean slash, not backslash.
people on this website will complain about the stupidest shit
AWS should wrap it in Firecracker and offer it as a service
sorry - cloudflare is running this in production ? this is wasm ?
this basically becomes the first large scale deployment of wasm in the world right ?
can someone talk about the engineering choices here. why this ? why not rust/java/c++...any of that ? a people perspective.
this basically becomes the first large scale deployment of wasm in the world right ?
can someone talk about the engineering choices here. why this ? why not rust/java/c++...any of that ? a people perspective.
Let me bring you back to 2017: https://blog.cloudflare.com/introducing-cloudflare-workers/
I'm not sure what to explain here? It's a runtime based on V8 to run JS and WASM code. Used by Cloudflare to run on edge. Why not just rust/java/c++? Well, good luck running that in multi-tenant environment.
I'm not sure what to explain here? It's a runtime based on V8 to run JS and WASM code. Used by Cloudflare to run on edge. Why not just rust/java/c++? Well, good luck running that in multi-tenant environment.
[deleted]
What exactly are the obstacles prohibiting multiple tenants from running rust/java/c++ on the edge?
Many reasons.
First, all 3 allow far too much: uncontrolled file system access, uncontrolled network access.
Second, customer's code cannot be trusted. Running unknown code on your server leaves with huge attack surface.
Third, isolation to deal with first two is expensive: resources and cold-start.
Third+, the point of running code on edge is for it to be quick. No one will use it if your cold-start time is higher network round-trip, and you're not going to get paid a lot if you have to run customer code even if not in use.
Fourth, running WASM allows unified runtime without any dependencies:
- Java, which JVM do you target? What language version do you target? How often you upgrade? Do you run one JVM per tenant? How do you deal with cold-start times?
- Rust/C++ which architecture your servers use? What if you want to switch to ARM? What if it's mixed? Which version of ARM it is? Can I use AVX-512?
- WASM: WASM is WASM. You don't care if customer compiled rust or C++ or Go to get that wasm.
First, all 3 allow far too much: uncontrolled file system access, uncontrolled network access.
Second, customer's code cannot be trusted. Running unknown code on your server leaves with huge attack surface.
Third, isolation to deal with first two is expensive: resources and cold-start.
Third+, the point of running code on edge is for it to be quick. No one will use it if your cold-start time is higher network round-trip, and you're not going to get paid a lot if you have to run customer code even if not in use.
Fourth, running WASM allows unified runtime without any dependencies:
- Java, which JVM do you target? What language version do you target? How often you upgrade? Do you run one JVM per tenant? How do you deal with cold-start times?
- Rust/C++ which architecture your servers use? What if you want to switch to ARM? What if it's mixed? Which version of ARM it is? Can I use AVX-512?
- WASM: WASM is WASM. You don't care if customer compiled rust or C++ or Go to get that wasm.
on the java stuff - why not something like graalvm or https://github.com/landlord/landlord ?
It does seem a lot of investment has happened in Java around this very problem. JVM bytecode has been relatively stable over decades.
Just wondering if it makes sense to make that investment. Some of these problems u will encounter when WASM gains a GC anyway. This is one of the big reasons why Graal doesnt target wasm backend. So this - one runtime/gc vs multiple is something that is a problem ull have to solve anyways.
Just wondering if it makes sense to make that investment. Some of these problems u will encounter when WASM gains a GC anyway. This is one of the big reasons why Graal doesnt target wasm backend. So this - one runtime/gc vs multiple is something that is a problem ull have to solve anyways.
Well, landlord is unknown to me, but it has all caps "EXPERIMENTAL" and had[1] 3 people working on it, so I wouldn't use it in production.
GraalVM is interesting, and it has isolates and from my memory it has plenty of sandboxing features like limiting network and file system access. However, it has some big downsides: it's Oracle, people still associate it with your regular JVM and all its downsides. Yeah, it can match v8 in performance if you let it warm up (it takes longer for it to warm up compared to V8.) and it's even further from what CF does in terms of compatibility with existing ecosystem.
CloudFlare workers have single digit cold-start time[2]. GraalVM is...200ms and that is considered blazing fast by JVM standards. Takes longer and slower at runtime and probably more memory consumed.
Remember, we're not talking about long-running services, we're talking about short-lived request handlers in JavaScript that run on edge. Pricing for workers is per request. It's in CF interests to serve customers requests as fast as possible. Also remember that customers want to write JavaScript.
Why is Oracle an issue? GraalVM is under GPLv2 which does not cover patents. Some performance and security features locked in Enterprise version. In addition, first production-ready version was in 2019, CF already launched workers by then.
[1]: Last commit 2018. I doubt this is a feature complete software...
[2]: https://blog.cloudflare.com/eliminating-cold-starts-with-clo...
GraalVM is interesting, and it has isolates and from my memory it has plenty of sandboxing features like limiting network and file system access. However, it has some big downsides: it's Oracle, people still associate it with your regular JVM and all its downsides. Yeah, it can match v8 in performance if you let it warm up (it takes longer for it to warm up compared to V8.) and it's even further from what CF does in terms of compatibility with existing ecosystem.
CloudFlare workers have single digit cold-start time[2]. GraalVM is...200ms and that is considered blazing fast by JVM standards. Takes longer and slower at runtime and probably more memory consumed.
Remember, we're not talking about long-running services, we're talking about short-lived request handlers in JavaScript that run on edge. Pricing for workers is per request. It's in CF interests to serve customers requests as fast as possible. Also remember that customers want to write JavaScript.
Why is Oracle an issue? GraalVM is under GPLv2 which does not cover patents. Some performance and security features locked in Enterprise version. In addition, first production-ready version was in 2019, CF already launched workers by then.
[1]: Last commit 2018. I doubt this is a feature complete software...
[2]: https://blog.cloudflare.com/eliminating-cold-starts-with-clo...
There's a bit of a catch 22 problem with these other language runtimes in that because they haven't been battle-tested in security-hostile environments, it's harder to choose them for security-critical use cases. But that in turn means they'll never be battle-tested.
The original JVM was intended to provide secure sandboxing for "applets" but that use case failed in the market, and instead JVM became focused on use cases where isolation isn't important. Years later as security research became stronger, all sorts of holes were found in the JVM's sandbox. Presumably those holes were fixed, but if we take JVM and use it in a security-critical environment again, probably a bunch of new holes get found pretty quick?
(I don't know anything about Graal specifically, I guess it's an alternative JVM? But how much security research has it had?)
Whereas V8 has had constant security research and real attacks over the course of about 15 years. It's certainly not bullet-proof either but we have a pretty good idea of just how much of a risk it is.
Again, catch 22, there's seemingly no path forward for these VMs to prove themselves. I don't know what to do about that, but that's where we find ourselves.
The original JVM was intended to provide secure sandboxing for "applets" but that use case failed in the market, and instead JVM became focused on use cases where isolation isn't important. Years later as security research became stronger, all sorts of holes were found in the JVM's sandbox. Presumably those holes were fixed, but if we take JVM and use it in a security-critical environment again, probably a bunch of new holes get found pretty quick?
(I don't know anything about Graal specifically, I guess it's an alternative JVM? But how much security research has it had?)
Whereas V8 has had constant security research and real attacks over the course of about 15 years. It's certainly not bullet-proof either but we have a pretty good idea of just how much of a risk it is.
Again, catch 22, there's seemingly no path forward for these VMs to prove themselves. I don't know what to do about that, but that's where we find ourselves.
You have to use heavier isolation mechanisms with those languages -- processes, containers, virtual machines. These are too heavy to support thousands of tenants per machine. Edge locations are typically smaller clusters, and you typically want all your customers to present in every point of presence, so you need to pack them tighter. V8 isolates are light enough for this to work and be cost-effective.
Is this just to cover their tracks so startups don't think they'll get locked in?
Maybe, but I think it's probably more related creating a larger Workers ecosystem.
Right now, you can't use most NPM modules on CF Workers since this is a custom runtime which is also pretty barebones (probably by design).
Deno in comparison offers a rich standard library which solves plenty, but they are also working on a compat layer for Node modules. And the Deno ecosystem is also growing, probably because you can run it anywhere.
Right now, you can't use most NPM modules on CF Workers since this is a custom runtime which is also pretty barebones (probably by design).
Deno in comparison offers a rich standard library which solves plenty, but they are also working on a compat layer for Node modules. And the Deno ecosystem is also growing, probably because you can run it anywhere.
No the author has created and maintained many open source projects. I imagine they advocated heavily for this.
Thanks. Indeed, I always expected to release this code eventually and I'm very happy that it's finally happened. Also very happy we could do it under an actual open source license.
We've always designed Workers around open standard APIs, so even without this, Workers-based code should not be too hard to port to competing runtimes. But, this makes it much easier to move your code anywhere, with bug-for-bug compatibility.
You can't build a successful developer ecosystem that has only one provider. We know that. We'd rather people choose Cloudflare for our ability to instantly and effortlessly deploy your application to hundreds of points of presence around the world, at lower cost than anyone else. :)
We've always designed Workers around open standard APIs, so even without this, Workers-based code should not be too hard to port to competing runtimes. But, this makes it much easier to move your code anywhere, with bug-for-bug compatibility.
You can't build a successful developer ecosystem that has only one provider. We know that. We'd rather people choose Cloudflare for our ability to instantly and effortlessly deploy your application to hundreds of points of presence around the world, at lower cost than anyone else. :)
Thank you for releasing this! Had a question: if I have worker code that uses other Cloudflare storage APIs like KV or R2, what would you recommend as far as shimming those calls so this code could run via workerd (but, for example, just use basic process-local in-memory storage for now.) Is that doable? For my use case durability isn’t that important and I’d like to offer people the ability to self host my code via workerd.
workerd includes implementations of the KV and R2 binding APIs, which convert all your calls into HTTP requests under the hood. You can point that at another Worker or to a separate HTTP service to implement the storage behind them. We plan to provide some example implementations in the future that store to disk or a database.
amazing, thank you!
re: self hosting,
I'm curious on the use cases for self hosting? Ie i have a heavy interest in self hosting. I also find workerd very interesting. Though i'm struggling to think of reasons why i'd build my apps around workerd instead of just a process.
If i was dedicated to WASM, Perhaps workerd might be a better solution than wasmer, unsure.
I'm curious on the use cases for self hosting? Ie i have a heavy interest in self hosting. I also find workerd very interesting. Though i'm struggling to think of reasons why i'd build my apps around workerd instead of just a process.
If i was dedicated to WASM, Perhaps workerd might be a better solution than wasmer, unsure.
The use case I'm referring to is where someone (in this case, me) publishes code intended to be run on Cloudflare Workers or self hosted with workerd.
Reasons you'd write first party code targeting workerd would be a different question.
Reasons you'd write first party code targeting workerd would be a different question.
Thanks for workerd! I saw a tweet from you mention that workerd could be used as a reverse-proxy (a la nginx), but the github readme is scant on the details and ends with (TODO: Fully explain how to get systemd to recognize these files and start the service.).
---
Cloudflare... uses... workerd, but adds many additional layers of security on top to harden against such bugs. However, these measures are closely tied to our particular environment... and cannot be packaged up in a reusable way.
Durable Objects are currently supported only in a mode that uses in-memory storage -- i.e., not actually "durable"... Cloudflare's internal implementation of this is heavily tied to the specifics of Cloudflare's network, so a new implementation needs to be developed for public consumption.
...the runtime parts I was most curious about couldn't be open-sourced :(
---
Cloudflare... uses... workerd, but adds many additional layers of security on top to harden against such bugs. However, these measures are closely tied to our particular environment... and cannot be packaged up in a reusable way.
Durable Objects are currently supported only in a mode that uses in-memory storage -- i.e., not actually "durable"... Cloudflare's internal implementation of this is heavily tied to the specifics of Cloudflare's network, so a new implementation needs to be developed for public consumption.
...the runtime parts I was most curious about couldn't be open-sourced :(
The config format is defined and documented here:
https://github.com/cloudflare/workerd/blob/main/src/workerd/...
We definitely need to provide more higher-level documentation around this, which we're working on, but if you're patient enough to read the schemas then everything is there. :)
To act as a proxy, you would define an inbound socket that points to a service of type `ExternalServer`. There are config features that let you specify that you want to use proxy protocol (where the HTTP request line is a full URL) vs. host protocol (where it's just a path, and there's a separate Host header), corresponding to forward and reverse proxies.
Next you'll probably want to add some Worker logic between the inbound and outbound. For this you'd define a second service, of type `Worker`, which defines a binding pointing to the `ExternalServer` service. The Worker can thus send requests to the ExternalServer. Then you have your incoming socket deliver requests to the Worker. Voila, Workers-based programmable proxy.
Again, I know we definitely need to write up a lot more high-level documentation and tutorials on all this. That will come soon...
https://github.com/cloudflare/workerd/blob/main/src/workerd/...
We definitely need to provide more higher-level documentation around this, which we're working on, but if you're patient enough to read the schemas then everything is there. :)
To act as a proxy, you would define an inbound socket that points to a service of type `ExternalServer`. There are config features that let you specify that you want to use proxy protocol (where the HTTP request line is a full URL) vs. host protocol (where it's just a path, and there's a separate Host header), corresponding to forward and reverse proxies.
Next you'll probably want to add some Worker logic between the inbound and outbound. For this you'd define a second service, of type `Worker`, which defines a binding pointing to the `ExternalServer` service. The Worker can thus send requests to the ExternalServer. Then you have your incoming socket deliver requests to the Worker. Voila, Workers-based programmable proxy.
Again, I know we definitely need to write up a lot more high-level documentation and tutorials on all this. That will come soon...
It is also to provide a more accurate testing environment when doing development before deploying.
absolutely key point here. miniflare doesn't allow you to check for conditions in which cloudflare might not fulfill a promise, but can't actually be tested for as the infrastructure is simply represented as an artifact currently with miniflare
Even if the answer is yes, I still think it's a good thing.
Lol, considering how many just use AWS or use Firestore or a myriad of other vendor lock in solutions for everything, sadly no-one really cares about lock in anymore.
That idea makes the implicit assertion that the only thing valuable about the code is that someone else might get it running in production, and not that they actually published their production runtime for the world to inspect, debug, and offer improvements to.
This is awesome and probably should have been a priority from day one. I'm sure it will boost the Workers ecosystem.
Anyone else thinks the name is kinda weird? After reading the article it makes sense that it's "worker d" but I first read it as "work erd" or a single word like "worked" but with a rogue R in the middle.
Anyone else thinks the name is kinda weird? After reading the article it makes sense that it's "worker d" but I first read it as "work erd" or a single word like "worked" but with a rogue R in the middle.
This comes from unix tradition, where you have servers like httpd, smtpd, sshd, systemd, etc.
Honestly, it's a boring name. We had a big debate over naming with a lot of interesting ideas, but ultimately every idea was hated by someone. No one loves workerd, but no one hates it, so here we are! Oh well.
Honestly, it's a boring name. We had a big debate over naming with a lot of interesting ideas, but ultimately every idea was hated by someone. No one loves workerd, but no one hates it, so here we are! Oh well.
Good luck getting that to stick (in terms of correct pronunciation) - unless folks have specifically read that explanation, you'll be hearing "work-erd" everywhere :)
Thanks that makes more sense!
Obviously I'm not a Unix guy and looking at the downvotes on my previous comment, people seem bothered by that :)
Obviously I'm not a Unix guy and looking at the downvotes on my previous comment, people seem bothered by that :)
I've dug a bit on the OSS repo [2], and here are some of the findings I got:
Open sourcing the engine, mixed with their recent announcement on a $1.25B investment fund for startups built on workers [4] I think will propel a lot the Wasm ecosystem... which I'm quite excited about!
[1] https://twitter.com/KentonVarda/status/1523666343412654081
[2] https://github.com/cloudflare/workerd
[3] https://www.npmjs.com/package/workerd
[4] https://blog.cloudflare.com/workers-launchpad/