1

Our team is maintaining an app using Sails.js framework, this app serves as an admin panel for a larger app and as such does not see much traffic. To streamline it and minimize moving parts, we wanted to remove the Redis dependency that sails uses by default for its session store (https://sailsjs.com/documentation/reference/configuration/sails-config-session).

We would prefer to replace the session store with a cookie store or LocalStorage that would be on the user's machine. Sails.js claims that their session store relies heavily on express's session store. We stumbled upon a cookie-based store (https://github.com/expressjs/cookie-session) but I'm confused about integrating it. I see that config/session.js file in Sails defines an adapter for its session store, but I'm assuming that would be incompatible with the above library without an additional wrapper. Searching for Sails adapters brings me to database adapters instead of the session store ones. Am I overcomplicating this? Can the above library (or maybe a simple LocalStorage alternative) be tied into Sails in place of Redis?

Alexander Tsepkov
  • 3,400
  • 2
  • 31
  • 51
  • Hey Alexander, is the sails application distributed or running on a single server? – Glen Dec 23 '17 at 10:44
  • It's currently running on a single server (single instance). However, the team does want to roll out a more fault-tolerant version in the future, which will probably end up being deployed in a distributed manner (we're currently using a single docker container for it, and have been considering Kubernetes for production setup). – Alexander Tsepkov Jan 12 '18 at 14:50

1 Answers1

2

I guess it could be the case that you are over-complicating it. Here are a couple of options for you:

Option 1: The default Sails session store

Out of the box, Sails uses the default memory store bundled in the underlying session middleware. This session store is an in memory store and therefore; a) does not scale passed a single instance, b) requires every user to login again after a restart of the Sails application and c) is not recommended for production environments.

With that said, I am currently using the default memory store in a production application right now. The application is quite basic and very stable, with changes made around once per quarter. After a restart, users simply login again and their sessions are recreated.

This is certainly a solid option for the first launch of your application, particularly if you have no plans on scaling it out to multiple servers in the immediate future.

To use the default Sails session store, don't make any changes to the config/session.js file or if you have already configured Redis, be sure to comment out the following lines in config/session.js:

// adapter: 'redis',

// host: 'localhost',
// port: 6379,
// ttl: <redis session TTL in seconds>,
// db: 0,
// pass: <redis auth password>,
// prefix: 'sess:',

Option 2: Scalable cache stores

As Sails session integration leans heavily on Express and Connect, you can use any session adapter written for Connect/Express with Sails, as long as you use a compatible version.

A complete list of compatible Connect based Express session stores is available here.

When it comes to design specific cache stores, the two obvious options in my opinion are Memcached making use of the connect-memjs package available here and Redis which Sails supports out of the box.

Memcached is a simple volatile cache server. It allows you to store key/value pairs limited to strings up to 1MB, where as Redis is a bit more than a cache server but can act as a cache as well, storing key/value pairs up to 512MB. For a more complete comparison on Redis vs Memcached see here.

Option 3 : Using a database

If you already have a Mongo, Couch, Dynamo or MSSql Database configured in your stack, you could consider making use of it as the session store. They all already have Connect based packages. Links to each can be found in the complete list of compatible Connect based Express session stores above.

Setup for Options 2 and 3 are very similar. Examples can be found on the Sails.js website on the page you mentioned. Setting up a database like Mongo is as simple as:

A) Install the connect-mongo package

npm install connect-mongo --save

B) Change the adapter in config/session.js:

adapter: 'connect-mongo',

C) Add the optional adapter values relevant to your database:

url: 'mongodb://user:pass@host:port/database',
collection: 'sessions',
auto_reconnect: false,
ssl: false,
stringify: true

Alternatively: Cookies

If you have no need for sessioning at all. You could as you mentioned push alot of this functionality out to the client by using cookies.

Sails has built in functionality for getting and setting cookies.

With regards to managing cookies, you could do this at either the controller level for controller based cookies or in middleware for more global data.

To get cookies on the incoming request you can use dot notation. For example:

req.cookies.username;

And to set cookies on the response you can use JSON. For example:

res.cookie('username', 'John Smith', { maxAge: 900000, httpOnly: true });

In my opinion, there would be a lot of manual overhead with taking this alternative. You would also have to consider the security implications, as all information stored in the cookie would be accessible through the developer console of the browser. In comparison with using Sails session, where only the Sails generated session ID is available clientside.

Glen
  • 1,118
  • 8
  • 17