It would be great to see more writing on what DO's enable compared to the "existing paradigms". Fo
It would be great to see more writing on what DO's enable compared to the "existing paradigms".
For example, I understand the "one DO per chat" use case well. That data likely scales well under the 10gb limit. I understand there's other benefits here like persistent WS connections and so forth.
But for use cases like one DO per user, having not built an app in a "one DB per user" architecture before, I wonder "why not just go the route of a multi-tenant DB... seems a lot more simple for most use cases". It's also a "standard" and easy to wrap your head around. Just spin up a relational DB on one of many vendors and go about your day
But then for other use cases where they are less granular, like "one DO per [insert large entity]", then I wonder if 10gb is too limited for this [larger scoped entity]. Like "one DO per Zip Code to store all Places like a google map place entity". Maybe 10gb is not enough when you are further zoomed out
On the other hand, when the entity is more granular/lower level, like "one DO per todo in a todo app" (i guess this is similar to the chat app use case mentioned above), I then wonder, is it worth the extra complexity for this todo app when the "todo" entity might be straight forward in a normal muti tenant db architecture.
I'm not a professional dev by day so perhaps I don't have the experience/knowledge to think outside the box for this new DO architecture... but I hope the above comments help explain where it's tougher for me to reason about DOs and I just bounce around thinking the above
For example, I understand the "one DO per chat" use case well. That data likely scales well under the 10gb limit. I understand there's other benefits here like persistent WS connections and so forth.
But for use cases like one DO per user, having not built an app in a "one DB per user" architecture before, I wonder "why not just go the route of a multi-tenant DB... seems a lot more simple for most use cases". It's also a "standard" and easy to wrap your head around. Just spin up a relational DB on one of many vendors and go about your day
But then for other use cases where they are less granular, like "one DO per [insert large entity]", then I wonder if 10gb is too limited for this [larger scoped entity]. Like "one DO per Zip Code to store all Places like a google map place entity". Maybe 10gb is not enough when you are further zoomed out
On the other hand, when the entity is more granular/lower level, like "one DO per todo in a todo app" (i guess this is similar to the chat app use case mentioned above), I then wonder, is it worth the extra complexity for this todo app when the "todo" entity might be straight forward in a normal muti tenant db architecture.
I'm not a professional dev by day so perhaps I don't have the experience/knowledge to think outside the box for this new DO architecture... but I hope the above comments help explain where it's tougher for me to reason about DOs and I just bounce around thinking the above