4 ms·

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

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

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.