31–40 of 103 posts
Earlier 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.
Holy return of tuple spaces! Are there any features for controlling consistency, or is it just YOLO last write wins?
Are 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.
If you can find a good Javascript library for doing it you can build it into your Worker with Webpack.
Are 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.
No big dataset needed, just some regex and if/then statements. If you still want a library then you can try https://github.com/faisalman/ua-parser-js
Dupe https://news.ycombinator.com/item?id=18092660
Earlier quoted context omitted.
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?
One write per second, per key plus eventually consistent does limit the functionality a bit. You're right for some use cases though.
Earlier quoted context omitted.
One write per second, per key plus eventually consistent does limit the functionality a bit. You're right for some use cases though.
Where are you getting 1 write per second from?
Earlier quoted context omitted.
If you can find a good Javascript library for doing it you can build it into your Worker with Webpack.
It's not finding a parser that I find problematic, it's the dataset needed. My understanding is that the workers are limited to 128MB of ram and that they may be 'restarted' at any time. Datasets for accurate browser detection would be really tight in fitting into that amount of RAM when combined with whatever else you may be doing and you have to deal with load / parse time whenever a worker is restarted. This seems…
Our hope is that anyone could create such an API, not just Cloudflare. Just like we are building storage on top of workers, we hope to eliminate the distinction between what is possible for a Cloudflare employee and what is possible for any of our customers.
Are 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!
Holy 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.
One great example of why this would matter to me - could workers ever institute a coordinated rate limiting function using this KV store?