Closed davidsharff closed 7 years ago
First pass at the schema below (expressed in YAML for readability). We'll start with only a redux server and write the resulting JSON to disk after each transaction.
@NateMeyvis let me know if you have any thoughts.
# app-state
users:
- id: key # can't key on username because they can be changed.
email: string
...
props:
- id: key
description: string
...
propGroups: # TODO: is there a better noun for these?
- id: key
operator: string # Greater, Occurs First, etc.
props:
- propId: propForeignKey
startingLine: number
- propId: propForeignKey
startingLine: number
...
wagers:
- id: key
playerId: userForeignKey
propGroupId: propGroupForeignKey
...
# server-local-state (best guess, really depends on auth decisions)
sessions:
- authToken: string
userId: userForeignKey
....
# client-local-state
# Note: may not be needed initially. Only reason I can think of is if we need to wait
# for server confirmation before allowing subsequent actions.
I'm no longer convinced that props
should exist apart from propGroups
. I feel like it's normalizing the data for it's own sake. I can think of no time we'd want to list a prop independent of its group. Maybe we may want to reuse a prop in other groups one day, but I think it's preferable not to worry about it for now.
Update
Since lines will ultimately be dynamic, we need to store the "locked-in" line for each wager. This value can also be used to potentially calculate market value when buy-backs are supported.
wagers:
- id: key
playerId: userForeignKey
propGroupId: propGroupForeignKey
line: number # as of time of the wager
For posterity (taken from local build app data):
{
"app": {
"users": [
{
"username": "davesharff@gmail.com",
"startingBubbles": 1000
},
{
"username": "davidsharff",
"startingBubbles": 1000
}
],
"propGroups": [
{
"id": 4822325878,
"operator": "1st to Occur",
"interest": 1,
"includedProps": [
{
"id": 4290584026,
"description": "Colonel Sanders is promoted to Brigadier General",
"startingLine": 120,
"currentLine": 120
},
{
"id": 9780233886,
"description": "Nolan Ryan throws ceremonial first pitch of Astros game and exceeds 80 mph",
"startingLine": -110,
"currentLine": -140
}
]
}
],
"bets": [
{
"propGroupId": 4822325878,
"propId": 4290584026,
"bubbles": 100,
"username": "davesharff@gmail.com",
"msTimeStamp": "1488052571989",
"effectiveLine": 120
},
{
"propGroupId": 4822325878,
"propId": 9780233886,
"bubbles": 100,
"username": "davidsharff",
"msTimeStamp": "1488052493234",
"effectiveLine": 110
}
],
"winningProps": [
{
"propGroupId": 4822325878,
"propId": 9780233886
}
]
},
"local": {
"authUsers": [
{
"username": "davesharff@gmail.com",
"userId": "google-oauth2|117428349818520446331"
},
{
"username": "davidsharff",
"userId": "twitter|3249993614"
}
]
}
}
We need an idea of our basic data schema early on. These problems are likely in @MortalLimit 's wheelhouse -- at a minimum I'll run my ideas by him upfront.
GraphQL is intriguing for iterative design/development and can tie into our database of choice later on.
I could see us storing data in flat files to start. We can worry about true persistence later.