@User @User @User Little bit of info here: https://discord.com/channels/595317990191398933/783765338692386886/811239747581509683 And a totally undocumented and not-at-all ready for open-source implementation here: https://github.com/glenstack/do/tree/main/src/data

Thank you! Even just seeing that the graphql-tools packages are compatible with workers is a big help.

No worries 😊 sorry I couldn't give it to you in a more polished manner.

Let me know if you take it any further!

Hey guys! I am working on a POC, was wondering if you think it would be to crazy usecase on DO or not.

User
   - Albums
           - Posts

A user can have N numbers of Albums and Post.

If you need posts to be immediately available after publication, then yeah, you could build that in DO. But if you'd be happy with a small amount of time after publication before showing a post, then I think you could also build that in KV.

Deletions in both KV and DO can be a pain, so if you need to be able to delete data, I'd give that a bit of thought as well. Edit: DO is actually fine with deletions. Forgot about the new

deleteAll()

.

I completely agree with deleting part with KV. I using KV for https://cool.bio takes long for sure. Few things on that. 1. If I had to queries, how complex it will get? I mean I was looking at the docs, didn't really understand this part. For example, if I had to get just 1 month's posts 2. How would you structure the data for this? I am asking this because I am not able to visulation how to, probably I dont know enough about DO.

I need to look at @User example to understand more how is he keeping the monthly data in statusflare :p

What's the recommended way to read data out a DO?

I tried to start writing our case down but it would take a while to give you enough context about statusflare 😄 I will start with a suggestion to decouple the data to collections - in statusflare there is DO namespace for account monitors, DO for account incidents, and another DO for something else is coming soon 🙊 How many albums and posts the user might have, how big you expect the object keys gonna be? I actually dont query time-based, I query all of them and then just filter based on what I want to return (as its super tiny dataset)

Say if its 90/10 read/write workload. Theres no way to read without blocking the DO?

When you need a nonconsistent read

Cache with KV and let users read from that

Let authors read from DO

Interesting. Do the writing please 🥺 It will help. I need to do small stuffs first to get the idea first. I guess its just difficult for me to visualize this ATM.

To start basic... You'd probably have three DO classes: one for each of "User", "Album" and "Post". You'd probably want to use the

newUniqueId()

generation for each of the instances of those classes. Depending on how you're doing auth, you'd probably 'enter' through

User

, which on it, lists the IDs of `Album`s that it owns. (Same for `Album`s → `Post`s).

Since you can list keys on a DO instance, I'd personally go with User:123456 has keys:

firstName → Greg
lastName → Brimble
album:78327 → 78327
album:25627 → 25627

And then do

state.storage.list({ prefix: "album:" })

which will return the list of album keys. Then you can just

env.Album.get(id)

.

Wouldnt this run up a crazy bill? 4xcharges? 1x worker. 1x userdo, 1xalbum do, 1x postdo?

What if I have 1M posts? Can one DO keep all of them?

So 4 requests

Depends on what you're calling crazy.

Like I wanted to have a model where every user is a DO object and other DOs communicate with a users DO

But the billing model makes this unfeasible

Please tell me there's a way to put

state.storage.list({ prefix: "album:", date: "startFrom" })

or something similar to quary?

Example a user can have their balance update multiple times a minute. Each balance update would incur a request charge to the DO

Even tho the request itself is super tiny

I don't think there's any limit to the number of key-values in a DO, but @User might know more than I.

But my design above isn't storing all posts in a single DO, each post is it's own DO.