4 ms·

Either im missing something here or something doesn’t make sense. How can something be a distributed system but be a strongly consistent system? Unless may be

Either im missing something here or something doesn’t make sense. How can something be a distributed system but be a strongly consistent system? Unless may be they lock all the instances of that object, in that case there is a performance penalty. But reading into the docs, They say that all clients subscribe to an object which is globally unique, and has only one instance. And cloudflare migrates it between regions intelligently. If thats the case, lets say there is User A (in US) and User B(in UK). Where is that globally unique object instance (chat) stored. It cant be edge here nor distributed, if its a single instance. If its distributed then there is no strong consistency, unless locks(there is a penalty to it)along with latency to sync data.

kentonv 5y ago
Each individual chat room is backed by a Durable Object, which is located in one location at a time, and strongly consistent. If the users of the chat room are all in one region, the chat room object can be expected to be located there. If users of a particular room are distributed around the world, Cloudflare will have to do its best to choose a location for the object "somewhere in the middle" -- but that's still better than just putting everything in us-east-1 or whatever.
- anaganisk 5y ago
  So instead of me choosing how and where data is stored cloudflare decides whats best, cool. But its not edge anymore. Instead of may be, cloud flare may choose to store either EU or US because it can’t store in the Atlantic for now. So its no better that us-east-1 or eu-west-2. Its not like Cloudlare can transmit data faster than GCP or AWS. It all turns down to If you need edge and distributed you get it, but its eventually consistent, which is cloudflare KV. If you need strong consistency, you don’t have edge and is not distributed, which is durable objects. The general push here seems to imply, its distributed, edge and also strongly consistent which is wrong. Also worth saying that durable objects doesn’t implement any rdbms/nosql db but rather expects us to build a db on top of it. I don’t know how if its better to maintain an inhouse DB monster and outsource server configuration or maintain a server config but have a good DB. If you are using a hosted Postgres/mongo DB, at best you moved your server near to the user but DB is still far away, which would not improve a thing. Workers are a good fit for stateless or async apps, tho.
  - kentonv 5y ago
    You started out saying you can't build complicated applications entirely on Workers. That's the point I was debating. It sounds like you're now saying that, yes, it is possible to build complex apps but they don't really count as "edge" in your mind. That's fine, "edge" isn't the point. The point is that we make it really easy to deploy an app globally. No need to think about multi-homing, no need to maintain multiple "regions", there's just one global network and the code runs everywhere. On the database point, to be clear, we're not expecting everyone to build their own database. We're saying that many applications don't actually need a monolithic globe-spanning database and may find that durable objects are a good fit as-is. For apps that do need a globe-spanning database, the expectation is that one or more of those will be built on top of Durable Objects in due time, and can then be reused by many apps. This is an ongoing process, we're certainly a long way from done.
    - anaganisk 5y ago
      There’s a reason why people chose RDBMS or NoSqL DBs right? At the end of the day durable object is a simple kv which is the api it provides right? How to build complex apps, without Indexes, or any other basic features existing DBs provide. Not every company can afford to build a new DB from basics, and you don’t expect to which is good. I agree workers shine for MVPs or even stateless functions. Or something with simple state. But once you start needing some basic features, we have to end up implementing complex loops/map-reduce to search, sort etc. Which is literally more code and maintenance. The benefit provided with server-less is quickly overcast by dev cost. Thats why I said at its current state Workers have a niche. And coming to edge I made a point to dig deep is because, Durable objects are not edge but global. Thats a huge difference. When the clients are far enough. Proponents of this feature here seem to imply they’re edge, distributed and strongly consistent, which is not exactly correct.

kentonv 5y ago

Each individual chat room is backed by a Durable Object, which is located in one location at a time, and strongly consistent. If the users of the chat room are all in one region, the chat room object can be expected to be located there. If users of a particular room are distributed around the world, Cloudflare will have to do its best to choose a location for the object "somewhere in the middle" -- but that's still better than just putting everything in us-east-1 or whatever.

anaganisk 5y ago
So instead of me choosing how and where data is stored cloudflare decides whats best, cool. But its not edge anymore. Instead of may be, cloud flare may choose to store either EU or US because it can’t store in the Atlantic for now. So its no better that us-east-1 or eu-west-2. Its not like Cloudlare can transmit data faster than GCP or AWS. It all turns down to If you need edge and distributed you get it, but its eventually consistent, which is cloudflare KV. If you need strong consistency, you don’t have edge and is not distributed, which is durable objects. The general push here seems to imply, its distributed, edge and also strongly consistent which is wrong. Also worth saying that durable objects doesn’t implement any rdbms/nosql db but rather expects us to build a db on top of it. I don’t know how if its better to maintain an inhouse DB monster and outsource server configuration or maintain a server config but have a good DB. If you are using a hosted Postgres/mongo DB, at best you moved your server near to the user but DB is still far away, which would not improve a thing. Workers are a good fit for stateless or async apps, tho.
- kentonv 5y ago
  You started out saying you can't build complicated applications entirely on Workers. That's the point I was debating. It sounds like you're now saying that, yes, it is possible to build complex apps but they don't really count as "edge" in your mind. That's fine, "edge" isn't the point. The point is that we make it really easy to deploy an app globally. No need to think about multi-homing, no need to maintain multiple "regions", there's just one global network and the code runs everywhere. On the database point, to be clear, we're not expecting everyone to build their own database. We're saying that many applications don't actually need a monolithic globe-spanning database and may find that durable objects are a good fit as-is. For apps that do need a globe-spanning database, the expectation is that one or more of those will be built on top of Durable Objects in due time, and can then be reused by many apps. This is an ongoing process, we're certainly a long way from done.
  - anaganisk 5y ago
    There’s a reason why people chose RDBMS or NoSqL DBs right? At the end of the day durable object is a simple kv which is the api it provides right? How to build complex apps, without Indexes, or any other basic features existing DBs provide. Not every company can afford to build a new DB from basics, and you don’t expect to which is good. I agree workers shine for MVPs or even stateless functions. Or something with simple state. But once you start needing some basic features, we have to end up implementing complex loops/map-reduce to search, sort etc. Which is literally more code and maintenance. The benefit provided with server-less is quickly overcast by dev cost. Thats why I said at its current state Workers have a niche. And coming to edge I made a point to dig deep is because, Durable objects are not edge but global. Thats a huge difference. When the clients are far enough. Proponents of this feature here seem to imply they’re edge, distributed and strongly consistent, which is not exactly correct.