[duped]

A pattern I've seen is to take something like `{ "users": [{ "id": string, ... }]}` and flatten it into `{ "user_id": { ... } }` so you can deserialize directly into a hashmap. In that case I can see 65k+ keys easily, although for an individual query you would usually limit it.

[mpweiher]

Hmm...would all the user id's be known beforehand in this use-case?

[duped]

I wouldn't get worked up about the actual names of things I used here, but there's no difference between having the key contained in the user data versus lifted up to the containing object... every language supports iterating objects by (key, value).

You would do a query like "give me all users with age over 18" or something and return a `{ [id: string]: User }`

[mpweiher]

There is a huge difference between a fixed, constant set of keys vs. the keys being an open-ended set that depends on user data.

[duped]

Not really, this is a very minor difference that people exploit all the time to minimize the size of serialized data or make it more readable. This is a great example of bikeshedding.

[mpweiher]

Yes there is if you optimize for the former case.

If that optimization isn't for you, choose a different library.

If that optimization works for your use-case, it can make a huge difference.