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

[Feat.] add FastCache class responsible for providing in memory cache #53

Open
rajatkb opened this issue Mar 20, 2020 · 2 comments
Open
Assignees
Labels
deadline For issues that specifically has a deadline. gssoc20 GSSOC label for gscco20 tag medium GSSOC label for beginner tag

Comments

@rajatkb
Copy link
Owner

rajatkb commented Mar 20, 2020

For large repeated queries whose results are not frequently changing, it's better to have them cached, than have them repeatedly evaluated. We can use node-cache , as a lightweight solution for caching.

REQUIREMENT

  • Implement class FastCache in services , which will use node-cache internally and facilitate usage

Where to look

  • src/services/ implement here

PS: Currenly admins are attending to the class design of it and reading up on doc. If anybody wants to pitch in can work on it. 😃

@rajatkb rajatkb added medium GSSOC label for beginner tag gssoc20 GSSOC label for gscco20 tag deadline For issues that specifically has a deadline. labels Mar 20, 2020
@rajatkb rajatkb self-assigned this Mar 20, 2020
@rajatkb rajatkb changed the title [Feat.] add utility class responsible for provided in memory cache [Feat.] add FastCache class responsible for providing in memory cache Mar 20, 2020
@secretshardul
Copy link

Redis would be a better fit for this case. This is because your server needs to scale.

For example during peak load your backend scales to a 4 server cluster. With node-cache package each node server will have it's own cache, defeating the purpose of caching. Better have a dedicated Redis server to handle this.

@rajatkb
Copy link
Owner Author

rajatkb commented Apr 5, 2020

  • A Reddis will be a overkill for the purpose of storing in memory a few query results that may be repeated often. (trying to reduce network overhead of contacting mongodb)

  • Current implementation can be abstracted away with an interface to follow , later if required reddis can be introduced , swaping out the existing implementation.

  • Scaling is important but for now a lightweight implementation suffices for the usecase.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
deadline For issues that specifically has a deadline. gssoc20 GSSOC label for gscco20 tag medium GSSOC label for beginner tag
Projects
None yet
Development

No branches or pull requests

2 participants