Change default session store to cookie store when in production mode

[lfdebrux]

Change the default configuration of the kit so that when the kit is run in production (NODE_ENV=production) the cookie session store is used instead of the memory session store. The impact of this is that session data will default to be preserved between server restarts, and the user will not see a warning from express-session in their server logs every server restart.

This PR still defaults to using the memory session store when running the kit locally, and the configuration can still be overridden.

[BenSurgisonGDS]

LGTM

[joelanman]

I think there's a potential issue with this - cookies have a max size of about 4k, and will silently fail if you try to store more

[lfdebrux]

I think there's a potential issue with this - cookies have a max size of about 4k, and will silently fail if you try to store more

Hmm, okay, do we have user reports of this issue affecting them?

[joelanman]

no, but I'm not aware of anyone using this option - I dont think its even documented, and its the reason we didnt make it default

[joelanman]

discussed with @lfdebrux :

• would be useful to persist session, both locally as a user is making a prototype (and triggering restarts), and remotely where a hosting service may restart, especially on a free tier.
• cookie store failing over 4k is a problem - a text field could easily consume 4k
• file store is a possibility but again may fail on some hosting services
• if we dont recommend cookie store for this reason should we just remove it entirely?
• we don't want users to worry about the current memory store warning when running remotely - it will not affect them. If we stick with Memory store maybe we should squash that warning if possible

@lfdebrux to investigate multi cookie store which may give us the persistence without the 4k limit

[edwardhorsford]

Our prototype stores a lot in session memory.

I'm not entirely sure how to tell how much we're using, but I saved it off as json in a file. The raw file is 23 megabytes. Compressed is 2.4mb.

Even for a small service, 4k is a very low limit - you could easily breach it.

---

Aside - does this get sent to and from the client with each request? would that slow things down?

[lfdebrux]

Our prototype stores a lot in session memory.

I'm not entirely sure how to tell how much we're using, but I saved it off as json in a file. The raw file is 23 megabytes. Compressed is 2.4mb.

Thanks for the info, that is useful. Just to check, is that from multiple sessions with multiple users? Also, just out of interest, what is the composition of the session data? How many of the questions are checkboxes/radios, and how many are free-form text fields?

Even for a small service, 4k is a very low limit - you could easily breach it.

I think it depends on the kind of service and the kind of questions asked, but agree it is a little stingy. With splitting cookies we could get at most 80 KiB, which is a bit more generous, but perhaps still not enough?

Aside - does this get sent to and from the client with each request? would that slow things down?

Yes, that is a consideration.

[edwardhorsford]

@lfdebrux this is data pre-loaded with session defaults.

My service is a casework service, so we have seed records for a few thousand trainees. Within each trainee is a bunch of simulated data. We've also got a few sizeable datasets for use in autocompletes and in routes. One of them is probably what makes us 20mb rather than 2mb. I actually moved it out of session data for this reason, but think I may have a bug and have re-loaded it somewhere.

[joelanman]

to note, we changed to using files to store session #1658