Use file store for session data #1658
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
It looks like these helpers were added by @BenSurgisonGDS in commit 46a1a50, but never wired into place. Let's use them, they look great!
lfdebrux
changed the title
When running the kit locally this will preserve session data between restarts. When running online with a PaaS such as Heroku we expect for most service providers the storage will be ephemeral, so we can't guarangee the data will be preserved there.
lfdebrux
force-pushed
the
ldeb-session-store
branch
from
c0e93f8
to
3b89c44
Compare
3 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR removes support for the cookie session data store, and uses a file store instead.
When running the kit locally this will preserve session data between restarts, which is useful for users when they are editing their routes file a lot.
When running online with a PaaS such as Heroku we expect for most service providers the storage will be ephemeral, so we can't guarantee the data will be preserved there. There is a possibility that some service providers might make it difficult for the kit to save data to disk, but since we're doing this already with compiled CSS files and the like I think if that becomes an issue session storage will not be the only blocker.
File storage is potentially slower and more resource-intensive than memory storage, however for local development the advantage of preserving data is very clear, and even in production using this library has a it has a few advantages over the default memory store - the main one being that it makes sure to prune expired sessions, so is less liable to 'leak' memory over time. Using the same store locally and when hosted also seems preferable in terms of reducing complexity and failure modes.
The file store also has a major advantage over the previous solution, cookie storage, or any other client store, in that it is not bound by browser or HTTP restrictions, so prototypes can store a lot more data. For this reason this PR also removes the cookie store support, as we have no evidence of it being used, and we know that for some users the cookie store storage limits are considered harmful. The use case that the cookie store was added for, preserving session data during restarts while doing local development, is covered better by the file store, and we shouldn't keep code no one is using.
This PR resolves #1655.