Stateful Single Page Application with ASP.NET Core

Question

I'm building a simple shopping cart using Angular and ASP.NET Core with. There is no login require and user can always checkout and make payment as a guest. The front end would be built with Angular, with simple 3 dynamic components - Shop > Checkout > Payment path in a single path. I'm presuming I will be relying on Angular router to handle the page transition.

However, I'm thinking whether I should use session cookies to maintain the state of the application. For example if the user has added up the items into the cart, a clean refresh would not clear their progress and bring the user back to the beginning. If the user is on payment step, any refresh would not restart their session. I know some prefers to store the session in Localstorage but that's not my preference.

For normal ASP.NET application which renders the view via AJAX, I don't have to worry about this. However, how can I make sure the SPA is stateful and session will be timeout if its idle for certain amount of time?

Answer 1

At some point you'll need to work with storing data and having to query for it. A common way to handle this is to create REST web services to handle your data needs. The REST web services send and receive JSON which also happens to be what Angualar uses for the model. It's a pretty fluid integration.

If you build your application as an ASP.Net Core MVC API project, you can take a lot of the guesswork out of the solution.

AngularJS 2 has the concept of "Services" which is where you would put the actual AJAX calls to send to your REST API. You can stub it out while you are working out how you want the user interface to work, and then have it connect to the actual web service.

The benefit of this approach is that you can easily scale your application by adding more instances of the REST API behind a firewall.

Answer 2

These days the trend is to store the state on the client. This makes most sense when writing a fat client because we can store state where the logic is. The server calls will also be simpler because they can be stateless which brings in benefits in terms of easier deployment, easier scaling, easier debugging.

In the client the state can be saved in session storage which will survive a refresh. Session storage is well supported in all modern browsers. One exception is safari in private browsing, a sensible fallback here is to prevent refreshing and make the user confirm that they want to discard unsaved changes(like stackexchange does)