Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Matches should have outcomes #11

Open
vingkan opened this issue Feb 24, 2017 · 0 comments
Open

Matches should have outcomes #11

vingkan opened this issue Feb 24, 2017 · 0 comments
Assignees

Comments

@vingkan
Copy link
Collaborator

vingkan commented Feb 24, 2017

Since the application is entirely implemented with client-side code, there is no consistent process running to execute tasks like locking rosters and, more crucially, determining the outcome of matches.

Some solutions I have considered and short explanations of why I didn't pursue them further:

  • Write a server process to handle such tasks (considering this a last-ditch solution)
  • Determine match outcome upon observation by a client (couldn't ensure consistency of information)
  • Store event tree and derive outcomes from it (could severely slow Firebase reads)

I have implemented locking using relative timestamps (#10), leaving the task of determining match outcomes, which may still involve saving locked somewhere.

New focus: find a data structure that could store historical rosters for users and allow game outcomes to be derived properties. The trick is to do this without slowing down Firebase reads. The two main threats are deeply-nested data or having to enter a separate Promise to read from another set of nodes.

The data structure could be updated with "fresh" rosters anytime Database.isLocked() is called. This function is used in all methods that modify rosters and it is expected to stay that way. The function is called before the actual change, so this may not be a perfect solution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant