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?

2 Answers 2


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.

  • Yes. The persistence of data will be handled on Server Side, which I can handle via AJAX or Restful call back to the server. My question is what's the best approach to maintain the state of the View.
    – CalebC
    Jun 21, 2017 at 3:46
  • Did you go through the whole tutorial I linked to (at lest the services section). They cover that very question. Long story short, your Angular services both handle client state and interaction with the REST API. Jun 21, 2017 at 12:23

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)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.