Hey there. Just a foreword, without really knowing the architecture of your project, I can’t give the most definite answer, but hopefully we can get started in a general direction…
First of all, storing data in DynamoDB every time the user leaves a session is an option, but probably isn’t the best one (well… it’s DynamoDB so maybe it’s not so bad… but regardless), as you’ve noted, so let’s look at alternatives.
You mentioned two use cases here: Storing form data inbetween sessions on the same device, and storing form data across multiple devices. I’m choosing to distinguish them here because they may require two approaches.
The simpler way, assuming you’re building a browser app (you’re using Angular, so I’ll assume you are) handles only on-device persistence: you can use
localStorage is essentially memory that is persisted by the user’s browser until the user, or you, decide to clear it. Every
localStorage instance for any browser is specific to the origin of the page by which it was generated, so you don’t have to worry about other random apps having access to or overwriting your data.
You should be able to do something like
window.localStorage.set('form_data', <your_form_data>) or something similar to persist form data for that user, and you can refer back to it at some point later. However since
localStorage is specific to a single device, you will not be able to share session data between devices.
Another way that may allow you to share data between devices is by maintaining server sessions. This means that your app will need a server-side backend in some form. The gist of how this works is that you enable your Angular app to POST data to your backend with some way to identify whose data it is–common patterns are by use of tokens. What I’m about to explain is greatly oversimplified so I’d encourage you to do your own research, but the basic session flow is:
Browser requests a session from the server by passing some credentials which identify the user (This can be whatever you want, commonly it’s something secure like
The server validates those credentials and starts a session, returning a token. The token is the “key” that lets the server know who the user is.
It is common for the server to set an expiration time for these sessions, as in, your session token is only valid for 1 hour. During that hour, the server can maintain all of the data that has been passed back and forth between the browser and itself. After that hour, the server clears that data, and it invalidates the token that it issued.
That turned out to be a longer answer than I would have liked. I hope I was clear enough. Hope this helps you.
(E: I said cookies before. Cookies aren’t the best way to do this, so I removed them from here.)