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
Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Though we will be talking to Salesforce often as our "single source of truth" for data in production, it may be extremely useful to have caching functionality so that we don't have to keep hitting our Salesforce backend every time we want to do a search.
Say the time it takes Salesforce to respond to our API request is 2 seconds. If we want to, say, respond with updated search results every few key presses while the user is typing in the search field (i.e. debounce) then this wouldn't be feasible unless we had some intermediate cache layer.
Describe the solution you'd like
A clear and concise description of what you want to happen.
We could investigate multiple routes. One way is to use a fast key-value store such as Redis, however we'd want to investigate how we'd structure that data in a way that's meaningful to us, since it's purely key-value and not meant for storing JSON (though I've done it [maybe not the best way] in my personal projects).
Additional context
Add details, any other context or screenshots about the feature request here.
The text was updated successfully, but these errors were encountered:
Whoops, accidentally closed this, but reopened now. Does this require server side caching? From my understanding, Redis would be server side, and I'm not sure how valuable it would be under the current structure of only admins and volunteers touching the platform (also idt hosting a redis instance is cheap lol). If client side caching is an option, maybe we could look into client-side methods (service workers, web apis, etc).
Btw, I'm not really knowledgeable about caching and don't have much context on the issue so feel free to lmk if I'm mistaken anywhere.
@angadgarg25 what you said is absolutely right. The deeper issue would be if we have another layer of indirection, namely Salesforce—it could be quite time consuming for each request to have to go through our Express server and then to Salesforce to fetch data. The thought here was that we could at least investigate throwing all the Salesforce resource data into a cache, not necessarily caching at the level we have right now. That’s why I think we should table this as of now as we wait for more information on Salesforce integration.
Looping in @alan-fang to see if there’s anything to add onto this.
Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Though we will be talking to Salesforce often as our "single source of truth" for data in production, it may be extremely useful to have caching functionality so that we don't have to keep hitting our Salesforce backend every time we want to do a search.
Say the time it takes Salesforce to respond to our API request is 2 seconds. If we want to, say, respond with updated search results every few key presses while the user is typing in the search field (i.e. debounce) then this wouldn't be feasible unless we had some intermediate cache layer.
Describe the solution you'd like
A clear and concise description of what you want to happen.
We could investigate multiple routes. One way is to use a fast key-value store such as Redis, however we'd want to investigate how we'd structure that data in a way that's meaningful to us, since it's purely key-value and not meant for storing JSON (though I've done it [maybe not the best way] in my personal projects).
Additional context
Add details, any other context or screenshots about the feature request here.
The text was updated successfully, but these errors were encountered: