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

Create Expected Responses + Timeouts Datastore #65

Open
3 tasks
baileytincher opened this issue Mar 12, 2021 · 2 comments
Open
3 tasks

Create Expected Responses + Timeouts Datastore #65

baileytincher opened this issue Mar 12, 2021 · 2 comments

Comments

@baileytincher
Copy link
Contributor

When the socket client sends events such as edit_cell, it expects an acknowledgment from the server in the form of a cell_edited broadcasted message. Reasonably, this should happen in a short window of time (~few secs or less).

  • Create a data structure to store expected acknowledgments
    • Key: hash of some data on event that is known/expected (i.e. event_name+cell_id+uid+contents)
    • Should be in memory
    • Needs to have fast search by exact hash, insert, and remove
  • Set timeouts that check the store on their expiration
    • Check store for hash
    • if not in store, ignore/continue
    • if in store, remove from store + emit timeout error
  • When an event/error is received, remove from store (aka cancel timeout)
@baileytincher
Copy link
Contributor Author

@jtaylorchang since this will be heavily used, you may have concerns on performance. Any suggestions on data structures/libraries? We effectively need a non-nested dictionary. Can use an object but that may be slow? Also not sure how to deal with modifying objects when considering async actions.

In-memory DB libraries I've found on npm are ~3mb which I'm guessing is too big.

@jtaylorchang
Copy link
Member

Well since this is a global variable anyways with a single instance that isn't watched by renders, you can simply use a regular object and mutate it (rather than creating a new one or using an immutable). Immutability only matters for efficient component rendering. 3mb package is definitely too big since our bundle size is already getting large and 3mb is massive. (Also I think a database is overkill). Also I don't think you need to worry about race conditions when mutating the object anyways since it's single threaded

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

2 participants