Question posted in 
I want to store a variable sent from frontend (ReactJs) to my backend (asp.net core) for example this URL: http://localhost:3000/?inviteCode=TRIAL, I want to store the value TRIAL in any place (the backend is a higher priority) to use later.
The things made me confused I choosing which way to store it. I don’t want to store it in the InMemory Store (memcache) because I’ve used it in many places and this could cause out of memory on the host VM (I think so). Store it in the database is not a good idea to store a little value like this.
Store it in frontend cookies or local storage is a good solution but my priority is to store it in the backend.
So are there any solutions to store this value?
2
Answers
It looks like the only way left is another database on the same physical server as the application server (I’m assuming your current database is remote). SQLite might be the easiest option.
But in general, you will probably need this value in the future, in which case it’s better to save it to a database right away.
If not, then think again, whether these queries will really be so many to constantly overflow the VM (one-time overflow is not terrible, the operating system can handle it). And can you enlarge the VM as needed?
As a compromise, you could put memcache on a separate server.
We are now having a client app + web api as the backend, the data is sent from the client to the API backend, and I trust the data will be used within the API frequently so that you prefer to store it in backend.
Just like we know, web api is stateless so that we can’t store data in the session(each http connection will create a new session). To access the data more efficiently, we need to differ from each scenario. If we want to access the data in the react app, then storing it in localstorage is the best option, or in other words, we should store the data in the browser so that the js code and read it locally without any IO or remote connection.
If we want to access the data in the API, since we don’t have built-in session in the current scenario, we have to find some places to store the data -> we have memory and disk.
If we store the data in disk, we need IO, in this scenario, we can use database if we have plenty of this kind of data and the data won’t be changed frequently, store the data in the database like a Dictionary, even if it brings IO cost, but we have to do it, it might bring performance issue but since data is not huge, the query shall be fast. If we don’t have so much data to be stored, we can also write data into a json file or text file(depends on data format), but it’s still storing data into disk. SSD will help improve performance.
If we store the data in memory, we can use memory database like redis. Memory database will bring benefit when the data shall be changed frequently but it is required to be used frequently. Since the data is stored in memory, we don’t need disk IO, it will be much faster to get than visiting the normal database.