I would probably use an SQL-like database with a submissions table (id, title, url, sender, date, points), a users table (id, name) and a comments table (id, author, date, parent, submission, color, content).
If you prefer using maps, for each table (map), use id as the key and the rest of the fields as the fields for a structure used as the value for each entry (using a C struct, or a Python tuple, named tuple or dataclass, assuming these languages).
You may want to use the id field from the HN URLs. You could drop the submission field for the comments.
Edit: You also need to decide how to handle edited, deleted and flagged comments, and dupe and flagged submissions.
8 comments
[ 3.3 ms ] story [ 30.7 ms ] threadBut if you want recursion you might need to patch the schema (https://github.com/clayallsopp/graphqlhub).
https://github.com/Y2Z/monolith
If you prefer using maps, for each table (map), use id as the key and the rest of the fields as the fields for a structure used as the value for each entry (using a C struct, or a Python tuple, named tuple or dataclass, assuming these languages).
You may want to use the id field from the HN URLs. You could drop the submission field for the comments.
Edit: You also need to decide how to handle edited, deleted and flagged comments, and dupe and flagged submissions.
Or is that too simplistic?