Introducing Workers KV
21–30 of 103 posts
Re: Introducing Workers KV
#22Are you planning on releasing any of the architectural details behind this service? If you’re truly replicating to every PoP that’s quite a fan-out and I can see why you’re limited to 1 write per second per key!
Yes, we will. This is something we built internally and we'll talk about architecture at some point.
Re: Introducing Workers KV
#23Good work Kenton Varda getting his initials into the product name!
> There's no truth in the rumour that a KV store is a @KentonVarda store. Nor that it maps kentons to vardas.
Re: Introducing Workers KV
#24Re: Introducing Workers KV
#25Re: Introducing Workers KV
#26Are there any plans to provide browser detection in the worker API? I imagine it's possible to implement as a user now, but may be clunky to provide a dataset to work from. This seems like a killer feature to have on edge workers to allow serving optimized builds for based on browser feature support without paying the overhead of client side detection.
Re: Introducing Workers KV
#27This is really cool. Webapps are basically programs that are executed across the network; having fine-grained control over what happens at each layer (client, client service worker, edge nodes, proxy server, origin server) means more choices and complexity, but also so much more power.
The question I would ask is: once you have the ability to run code and store data on the network itself (which Cloudflare effectively is), why do you need an origin at all?
Re: Introducing Workers KV
#28Holy return of tuple spaces! Are there any features for controlling consistency, or is it just YOLO last write wins?
Re: Introducing Workers KV
#29Holy return of tuple spaces! Are there any features for controlling consistency, or is it just YOLO last write wins?
Last write wins. There are several features for controlling consistency that we have been prototyping. Based on how storage is used we will enable those as the product matures.
Re: Introducing Workers KV
#30Earlier quoted context omitted.
Last write wins. There are several features for controlling consistency that we have been prototyping. Based on how storage is used we will enable those as the product matures.
So why not strong eventual consistency and CRDTs? As they fit perfectly for such functions running on edge nodes and no silly limitations of 1 write per second necessary.