CODEWITHSUNDEEP
node.jsmongodbsession
McB
McB

Reputation: 1232

What is the best practice for storing rarely modified database values in NodeJS?

I've got a node app that works with Salesforce for a few different things. One of the features is letting users fill in a form and pushing it to Salesforce.

The form has a dropdown list, so I query salesforce to get the list of available dropdown items and make them available to my form via res.locals. Currently I'm getting these values via some middleware, storing them in the users session, and then checking if the session value is set, use them, if not, query salesforce and pull them in.

This works, but it means every users session data in Mongo holds a whole bunch of picklist vals (they are the same for all users). I very rarely make changes to the values on the Salesforce side of things, so I'm wondering if there is a "proper" way of storing these vals in my app?

I could pull them into a Mongo collection, and trigger a manual refresh of them whenever they change. I could expire them in Mongo (but realistically if they do need to change, it's because someone needs to access the new values immediately), so not sure that makes the most sense...

Is storing them in everyone's session the best way to tackle this, or is there something else I should be doing?

Upvotes: 0

Views: 55

Answers (1)

Ralph
Ralph

Reputation: 1679

To answer your question quickly, you could add them to a singleton object (instead of session data, which is per user). But not sure how you will manage their lifetime (i.e. pull them again when they change). A singleton can be implemented using a simple script file that can be required which returns a simple object...

But if I was to do something like this, I would go about doing it differently:

  1. I would create an API endpoint that returns your list data (possibly giving it a query parameters to return different lists).

If you can afford the data being outdated for a short period of time then, you can write your API so that it returns the response cached (http cache, for a short period of time)

  1. If your data has to be realtime fresh, then your API should return an eTag in the response of the API. The eTag header basically acts like a checksum for your data, a good checksum would be "last updated date" of all the records in a collection. Upon receiving a request you check if you have the header "if-none-match" which would contain the checksum, at this point, you do a "lite" call to your database to just pull the checksum, if it matches then you return 304 http code (not modified), otherwise you actually pull the full data you need and return it (alongside the new checksum in the response eTag). Basically you are letting your browser do the caching...

Note that you can also combine caching in points 1 and 2 and use them together.

More resources on this here: https://devcenter.heroku.com/articles/increasing-application-performance-with-http-cache-headers https://developers.facebook.com/docs/marketing-api/etags

Upvotes: 1

Related Questions