Create simple server and basic api model

[davidsharff]

We'll be using a standard node server with express.js.

For the API, I'd like to use/try GraphQL barring time constraints, and learning curve.

[davidsharff]

Initial rollout design (Redux server with fat client):

• Connect via websocket
• On connection:
  • Client subscribes to the server's redux store
  • Send client entire app state
• Client sends Redux style actions down the socket
  • Server dispatches action to local store
  • Send the entire resulting app state to all clients (via their subscription)
• Client wholesale replaces its current app state with the new version from the server

This will be fine while the application is in its infancy. We can tryout GraphQL later on when we need a more robust solution and/or have time.

[NateMeyvis]

If we ever have so much data that we need a more robust solution, Gonfalon will already be so awesome.

On Wed, Feb 8, 2017, at 09:16 PM, David Sharff wrote:

Initial rollout design:

• Connect via websocket
• On connection:
  • Client subscribes to the server's redux store
  • Send client entire app state
• Client sends Redux style actions down the socket
  • Server dispatches action to local store
  • Send the entire resulting app state to all clients (via their subscription) This will be fine while the application is in its infancy. We can tryout GraphQL later on when we need a more robust solution and/or have time. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub[1], or mute the thread[2].

Links:

1. https://github.com/davidsharff/gonfalon-sports-book/issues/2#issuecomment-278526839
2. https://github.com/notifications/unsubscribe-auth/AHNdh9IujIH1SnFBfflQ0WYpjF6SehGSks5rancTgaJpZM4L5JXs

[davidsharff]

If we ever have so much data that we need a more robust solution, Gonfalon will already be so awesome.

Most definitely. Coincidentally, the more likely pitfalls for the project/myself were covered in the latest xkcd:

https://xkcd.com/1796/

Update: Practically done with this implementation.

Modification: we're storing an array of clients on the server and call each directly after a state update (instead of relying on store subscriptions).

Only remaining item is to send the state on the initial connection.

[davidsharff]

If we ever have so much data that we need a more robust solution, Gonfalon will already be so awesome.

@NateMeyvis I wholeheartedly agree with your sentiment, however, it just hit me why the problem is more nuanced than data limits.

Using our own flat file "database" means we have no inherent definitions for relationships across the state. The result is no cascading updates, or foreign key validation. This becomes a problem as soon as you want to delete any record referenced in other areas of the state (like a prop or user). It’s manageable, but will require forethought to catch, and overhead to handle.

I’m still good with the spec as outlined, but wanted to document the concern for posterity.