14 ms·

Workerd: Open-source Cloudflare workers runtime

689 points by kentonv 4y ago

asim 4y ago
Kudos to Kenton who keeps delivering great stuff on Workers.
- kentonv 4y ago
  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/a265d5c22bf2a6bc6394aa54db517ff86d6c788c https://github.com/cloudflare/workerd/commit/a265d5c22bf2a6b...
  - 616c 4y ago
    Much respect for this response. Your tech work is obviously reputable but really wholesome to see humility and honesty on such cool big work.
aiansiti 4y ago
Is this just to cover their tracks so startups don't think they'll get locked in?
- williamstein 4y ago
  It is also to provide a more accurate testing environment when doing development before deploying.
  - superdug 4y ago
    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
- fsociety 4y ago
  No the author has created and maintained many open source projects. I imagine they advocated heavily for this.
  - kentonv 4y ago
    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. :)
    - gfodor 4y ago
      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.
      - kentonv 4y ago
        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.
        gfodor 4y ago
        amazing, thank you!
- resonious 4y ago
  Even if the answer is yes, I still think it's a good thing.
- thejosh 4y ago
  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.
- bastawhiz 4y ago
  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.
- pier25 4y ago
  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.
thegagne 4y ago
Hey congrats on the release! This is a big step and really helps build some trust in the platform.
rishsriv 4y ago
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/ https://datanarratives.com/
- ignoramous 4y ago
  > 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 https://news.ycombinator.com/item?id=32511577 [0] https://archive.is/Q18Gs https://archive.is/Q18Gs
  - rishsriv 4y ago
    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/ https://blog.cloudflare.com/relational-database-connectors/ [2] https://blog.cloudflare.com/whats-new-with-d1/ https://blog.cloudflare.com/whats-new-with-d1/
- icelancer 4y ago
  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.
  - rishsriv 4y ago
jtwebman 4y ago
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.
- kentonv 4y ago
  You might be interested in Durable Objects, which is essentially an actor model within Workers. https://blog.cloudflare.com/introducing-workers-durable-objects/ 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.
  - crabmusket 4y ago
    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/ http://ithare.com/scaling-stateful-objects/
  - htgb 4y ago
    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.
the_mitsuhiko 4y ago
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 ;))
- ceejayoz 4y ago
  Oh, there's worse; you can use emoji in filenames.
  - deleted 4y ago
    [deleted]
  - staticassertion 4y ago
    Anything other than null and `\` are valid on linux iirc
    - yencabulator 4y ago
      You mean slash, not backslash.
- kentonv 4y ago
  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.
  - teddyh 4y ago
    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.
    - jchw 4y ago
mwcampbell 4y ago
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?
- kentonv 4y ago
  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.
  - mwcampbell 4y ago
    See the top of this doc: https://developers.cloudflare.com/workers/learning/using-websockets https://developers.cloudflare.com/workers/learning/using-web...
    - kentonv 4y ago
      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/#durable-objects https://developers.cloudflare.com/workers/platform/pricing/#...
      - DenseComet 4y ago
        > 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.
gfodor 4y ago
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.
- gradys 4y ago
  What do you (or others) see as its advantages relative to other similar offerings like those of AWS, GCP, Deno, Netlify, etc.?
  - gfodor 4y ago
    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.
  - dirheist 4y ago
    Cloudflare offers web standard javascript API's out of the box and is very fast as is
- meah0 4y ago
  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.
  - madeofpalk 4y ago
    What part of the Cloudflare runtime looks v8 specific, rather than just (web) javascript specific?
  - gfodor 4y ago
    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.
arez 4y ago
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?
sandGorgon 4y ago
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.
- 0x457 4y ago
  Let me bring you back to 2017: https://blog.cloudflare.com/introducing-cloudflare-workers/ 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.
  - deleted 4y ago
    [deleted]
  - styren 4y ago
    What exactly are the obstacles prohibiting multiple tenants from running rust/java/c++ on the edge?
    - kentonv 4y ago
      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.
    - 0x457 4y ago
      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.
syrusakbary 4y ago
This is great. They mentioned a few months ago their will to open-source it [1] and now it's finally a reality, so props to Kenton and the Workers team on achieving it! I've dug a bit on the OSS repo [2], and here are some of the findings I got: 1. They are using a forked version of V8 with very small/clean set of changes (the diff with the changes is really minimal. Not sure if this makes sense, but it might be interesting to see if changes could be added upstream) 2. It's coded mainly in C++, with Bazel for the builds and a mix between CapNProto and Protocol Buffers for schema 3. They worked deeply the Developer Experience, so as developer you can start using `workerd` with pre-build binaries via NPM/NPX (`npx workerd`). Still a few rough edges around but things are looking promising [3]. 4. I couldn't find the implementation anywhere of the KV store. Is it possible to use it? How it will work? 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 https://twitter.com/KentonVarda/status/1523666343412654081 [2] https://github.com/cloudflare/workerd https://github.com/cloudflare/workerd [3] https://www.npmjs.com/package/workerd https://www.npmjs.com/package/workerd [4] https://blog.cloudflare.com/workers-launchpad/ https://blog.cloudflare.com/workers-launchpad/
- kentonv 4y ago
  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.
Existenceblinks 4y ago
> 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?
- drexlspivey 4y ago
  I don't know any JavaScript but i use workers for discord bots written in rust (and compiled to wasm).
thdxr 4y ago
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
- sixo 4y ago
  The post links to this: https://blog.cloudflare.com/mitigating-spectre-and-other-security-threats-the-cloudflare-workers-security-model/ 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.
dontlaugh 4y ago
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.
- kentonv 4y ago
  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.
  - dontlaugh 4y ago
    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.
    - atonse 4y ago
      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.
      - kentonv 4y ago
        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.
superdug 4y ago
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.
- pbowyer 4y ago
  https://news.ycombinator.com/item?id=32997774 https://news.ycombinator.com/item?id=32997774
merb 4y ago
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 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.
- azakai 4y ago
  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.
- vlovich123 4y ago
  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.
  - merb 4y ago
    thanks for the info, well yeah wizer still does not make it as fast as c++ v8
pier25 4y ago
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.
- kentonv 4y ago
  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.
  - pier25 4y ago
    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 :)
  - seriocomic 4y ago
    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 :)
BonoboIO 4y ago
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.
0xbkt 4y ago
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?
- kentonv 4y ago
  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. :)
rubenfiszel 4y ago
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 https://github.com/windmill-labs/windmill
- kentonv 4y ago
  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.
  - slothsarecool 4y ago
    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.
mirekrusin 4y ago
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?
- kentonv 4y ago
  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!
otar 4y ago
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.
munhitsu 4y ago
AWS should wrap it in Firecracker and offer it as a service
misiek08 4y ago
"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
deleted 4y ago
[deleted]
barrucadu 4y ago
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?
- kentonv 4y ago
  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.
- ontouchstart 4y ago
  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.
- gpm 4y ago
  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.
- Bombthecat 4y ago
  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
himekami3 4y ago
this appears very much like actor based concurrency/isolation model. why ?
j4ah4n 4y ago
> 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]
- mftb 4y ago
  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...
- ignoramous 4y ago
  A Community Group for Web-interoperable JavaScript runtimes (May 2022), https://archive.is/JIzMK https://archive.is/JIzMK.

689 points by kentonv 4y ago

asim 4y ago

Kudos to Kenton who keeps delivering great stuff on Workers.

kentonv 4y ago
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/a265d5c22bf2a6bc6394aa54db517ff86d6c788c https://github.com/cloudflare/workerd/commit/a265d5c22bf2a6b...
- 616c 4y ago
  Much respect for this response. Your tech work is obviously reputable but really wholesome to see humility and honesty on such cool big work.

aiansiti 4y ago

Is this just to cover their tracks so startups don't think they'll get locked in?

williamstein 4y ago
It is also to provide a more accurate testing environment when doing development before deploying.
- superdug 4y ago
  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
fsociety 4y ago
No the author has created and maintained many open source projects. I imagine they advocated heavily for this.
- kentonv 4y ago
  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. :)
  - gfodor 4y ago
    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.
    - kentonv 4y ago
      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.
      - gfodor 4y ago
        amazing, thank you!
resonious 4y ago
Even if the answer is yes, I still think it's a good thing.
thejosh 4y ago
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.
bastawhiz 4y ago
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.
pier25 4y ago
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.

thegagne 4y ago

Hey congrats on the release! This is a big step and really helps build some trust in the platform.

rishsriv 4y ago

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/ https://datanarratives.com/

ignoramous 4y ago
> 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 https://news.ycombinator.com/item?id=32511577 [0] https://archive.is/Q18Gs https://archive.is/Q18Gs
- rishsriv 4y ago
  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/ https://blog.cloudflare.com/relational-database-connectors/ [2] https://blog.cloudflare.com/whats-new-with-d1/ https://blog.cloudflare.com/whats-new-with-d1/
icelancer 4y ago
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.
- rishsriv 4y ago

jtwebman 4y ago

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.

kentonv 4y ago
You might be interested in Durable Objects, which is essentially an actor model within Workers. https://blog.cloudflare.com/introducing-workers-durable-objects/ 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.
- crabmusket 4y ago
  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/ http://ithare.com/scaling-stateful-objects/
- htgb 4y ago
  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.

the_mitsuhiko 4y ago

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 ;))

ceejayoz 4y ago
Oh, there's worse; you can use emoji in filenames.
- deleted 4y ago
  [deleted]
- staticassertion 4y ago
  Anything other than null and `\` are valid on linux iirc
  - yencabulator 4y ago
    You mean slash, not backslash.
kentonv 4y ago
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.
- teddyh 4y ago
  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.
  - jchw 4y ago

mwcampbell 4y ago

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?

kentonv 4y ago
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.
- mwcampbell 4y ago
  See the top of this doc: https://developers.cloudflare.com/workers/learning/using-websockets https://developers.cloudflare.com/workers/learning/using-web...
  - kentonv 4y ago
    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/#durable-objects https://developers.cloudflare.com/workers/platform/pricing/#...
    - DenseComet 4y ago
      > 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.

gfodor 4y ago

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.

gradys 4y ago
What do you (or others) see as its advantages relative to other similar offerings like those of AWS, GCP, Deno, Netlify, etc.?
- gfodor 4y ago
  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.
- dirheist 4y ago
  Cloudflare offers web standard javascript API's out of the box and is very fast as is
meah0 4y ago
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.
- madeofpalk 4y ago
  What part of the Cloudflare runtime looks v8 specific, rather than just (web) javascript specific?
- gfodor 4y ago
  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.

arez 4y ago

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?

sandGorgon 4y ago

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.

0x457 4y ago
Let me bring you back to 2017: https://blog.cloudflare.com/introducing-cloudflare-workers/ 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.
- deleted 4y ago
  [deleted]
- styren 4y ago
  What exactly are the obstacles prohibiting multiple tenants from running rust/java/c++ on the edge?
  - kentonv 4y ago
    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.
  - 0x457 4y ago
    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.

syrusakbary 4y ago

This is great. They mentioned a few months ago their will to open-source it [1] and now it's finally a reality, so props to Kenton and the Workers team on achieving it! I've dug a bit on the OSS repo [2], and here are some of the findings I got: 1. They are using a forked version of V8 with very small/clean set of changes (the diff with the changes is really minimal. Not sure if this makes sense, but it might be interesting to see if changes could be added upstream) 2. It's coded mainly in C++, with Bazel for the builds and a mix between CapNProto and Protocol Buffers for schema 3. They worked deeply the Developer Experience, so as developer you can start using `workerd` with pre-build binaries via NPM/NPX (`npx workerd`). Still a few rough edges around but things are looking promising [3]. 4. I couldn't find the implementation anywhere of the KV store. Is it possible to use it? How it will work? 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 https://twitter.com/KentonVarda/status/1523666343412654081 [2] https://github.com/cloudflare/workerd https://github.com/cloudflare/workerd [3] https://www.npmjs.com/package/workerd https://www.npmjs.com/package/workerd [4] https://blog.cloudflare.com/workers-launchpad/ https://blog.cloudflare.com/workers-launchpad/

kentonv 4y ago
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.

Existenceblinks 4y ago

> 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?

drexlspivey 4y ago
I don't know any JavaScript but i use workers for discord bots written in rust (and compiled to wasm).

thdxr 4y ago

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

sixo 4y ago
The post links to this: https://blog.cloudflare.com/mitigating-spectre-and-other-security-threats-the-cloudflare-workers-security-model/ 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.

dontlaugh 4y ago

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.

kentonv 4y ago
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.
- dontlaugh 4y ago
  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.
  - atonse 4y ago
    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.
    - kentonv 4y ago
      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.

superdug 4y ago

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.

pbowyer 4y ago
https://news.ycombinator.com/item?id=32997774 https://news.ycombinator.com/item?id=32997774

merb 4y ago

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 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.

azakai 4y ago
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.
vlovich123 4y ago
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.
- merb 4y ago
  thanks for the info, well yeah wizer still does not make it as fast as c++ v8

pier25 4y ago

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.

kentonv 4y ago
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.
- pier25 4y ago
  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 :)
- seriocomic 4y ago
  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 :)

BonoboIO 4y ago

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.

0xbkt 4y ago

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?

kentonv 4y ago
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. :)

rubenfiszel 4y ago

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 https://github.com/windmill-labs/windmill

kentonv 4y ago
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.
- slothsarecool 4y ago
  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.

mirekrusin 4y ago

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?

kentonv 4y ago
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!

otar 4y ago

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.

munhitsu 4y ago

AWS should wrap it in Firecracker and offer it as a service

misiek08 4y ago

"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

deleted 4y ago

[deleted]

barrucadu 4y ago

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?

kentonv 4y ago
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.
ontouchstart 4y ago
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.
gpm 4y ago
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.
Bombthecat 4y ago
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

himekami3 4y ago

this appears very much like actor based concurrency/isolation model. why ?

j4ah4n 4y ago

> 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]

mftb 4y ago
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...
ignoramous 4y ago
A Community Group for Web-interoperable JavaScript runtimes (May 2022), https://archive.is/JIzMK https://archive.is/JIzMK.