locked
State management for .NET Core WebAPI RRS feed

  • Question

  • User1358036820 posted

    We are all told that Sessions in WebAPI are not a good idea as it is meant to be stateless.  However, in the real world people use them.

    We have a WebAPI that stores large objects per user.  Heres how it works:

    1. We get large object from 3rd party API
    2. Large object could be around 800kb so we store in session
    3. Customer can modify this object with a number of calls to our API
    4. Calls modify the object in Session State
    5. When finished we send the object back to 3rd party

    Questions

    1) Would it be better to store this object in database on our end which would introduce a data source on our end?

    2) Tests showed it would be slower to read/write database rather than session but is it worth the trade-off

    3) Is there any other alternative to managing a large object state apart from db/session

    We are looking at redeveloping some of the code so we are thinking if our backend is worth changing or sticking with.

    Any suggestions would be appreciated.

    Wednesday, September 23, 2020 8:46 AM

Answers

  • User475983607 posted

    We are all told that Sessions in WebAPI are not a good idea as it is meant to be stateless.  However, in the real world people use them.

    Session is is not used in Web API because Session requires a browser.  Cache is a better option on Web API.

    1) Would it be better to store this object in database on our end which would introduce a data source on our end?

    Depends on your unknown requirements.  A databases persist data while session is temporary.   It's a bit easier to debug if there's a history of the data.

    2) Tests showed it would be slower to read/write database rather than session but is it worth the trade-off

    Again, it depends on your unknown requirements and the architecture.  Database are often on a separate server and calls are asynchronous.  Also it is not clear why 800k is always needed on the web server.

    3) Is there any other alternative to managing a large object state apart from db/session

    Cache is more appropriate than Session for Web API.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Wednesday, September 23, 2020 10:39 AM

All replies

  • User475983607 posted

    We are all told that Sessions in WebAPI are not a good idea as it is meant to be stateless.  However, in the real world people use them.

    Session is is not used in Web API because Session requires a browser.  Cache is a better option on Web API.

    1) Would it be better to store this object in database on our end which would introduce a data source on our end?

    Depends on your unknown requirements.  A databases persist data while session is temporary.   It's a bit easier to debug if there's a history of the data.

    2) Tests showed it would be slower to read/write database rather than session but is it worth the trade-off

    Again, it depends on your unknown requirements and the architecture.  Database are often on a separate server and calls are asynchronous.  Also it is not clear why 800k is always needed on the web server.

    3) Is there any other alternative to managing a large object state apart from db/session

    Cache is more appropriate than Session for Web API.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Wednesday, September 23, 2020 10:39 AM
  • User-474980206 posted

    If the data is recoverable, than a cache is fine, if not then use a database to store. You can use a in memory database like redis.

    Wednesday, September 23, 2020 3:01 PM
  • User585649674 posted

    If the modification logic is not complex. You could convert the object to json and send it to browser. Make the changes to json in the browser. Send the final json back to server, which will forward to third party API.

    Else, Database is the approach. you can store the customer id, and object as json inside a table. Because database gives persistence.

    If you are using sessions, you can use only one server. In load balanced environment you might need sticky sessions. Or a separate server to hold the session.

    Ideally, the third party should give api to perform modification.

    Thursday, September 24, 2020 9:19 AM
  • User1358036820 posted

    The data is recoverable from 3rd party but a number of calls would need to be made in order to rebuild a large object.

    I am beginning to go towards caching.  The DB option by far would be slower as the object would need to be sent on every request including ajax calls to the api in which case a single page might make 4 or 5 calls depending on user interaction.

    We do use Redis as session storage so creating a provider on top of it for caching might be a good idea.  The session has worked for us well but now other requirements mean we have to reconsider.

    Appreciate all the tips.

    Thursday, September 24, 2020 3:01 PM