You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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:
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.The text was updated successfully, but these errors were encountered: