Besides the obvious (using MongoDB), how do I go about storing data that is never accessible by the client? It’s okay if it’s destroyed when the server shuts down.
Is there anything wrong with this approach:
server/file.js
secureVar = '';
Meteor.methods({
refreshToken: function () {
secureVar = getSecureThing();
...
});
And so then secureVar
could be accessed globally, but not on the client?
What’s the reason to not use the obvious, a collection, in this case?
The desire to keep the number of moving parts as minimal as possible. Seems overkill to engage MongoDB just to store a single variable server-side only.
I tried the above technique of having a global variable, seems to work.
@captsaltyjack thats perfectly acceptable unless it deals with application state. If it deals with state then you will likely run into scaling issues.
@copleykj Makes sense. Then MongoDB would be the proper place to store persistent application states for large scale apps. (this is a small scale)
//server
//create global session object
Sessions = {}
//on each connection to the server
Meteor.onConnection(function(connection){
//instantiate a dictionary labeled with the connection's unique id.
Sessions[connection.id] = {clientData:{}, time: Date.now()};
connection.onClose(function(){
//forget the client when they leave
delete Sessions[connection.id]
})
})
How about using server-side localStorage? localStorage is even non-volatile (it will persist after power loss) because the data is continually written to disk as a SQLite-style database file. You can even run basic SQL queries against this data if you like.