Lately I have been developing server-side web apps where I keep all the data in memory instead of using databases. Sounds crazy, right? Of course, for apps with huge amounts of data this would not work. For apps with smaller amounts of data, this works pretty good. Where the threshold goes, I don’t know yet, but I imagine most of SAAS apps can be developed this way:
Dump the data to a JSON file before the app instance gets restarted. When you want to restart the app, always run a task that makes sure the data has been stored before it gets restarted. Additionally you need backup in case something suddenly shut down your app. Dump therefor data to the JSON file at certain intervals, for example every 10th second. The data is stored into a specific file JSON file, but you should also have some timestamped backup files.
If data loss is not a big problem in your app, then save on more rare instances and skip the restart task.
Load all the data from the JSON file on startup of the app. If loading fails try reloading on certain intervals. For apps where data persistence is not important, you can continue with empty data if the loading fails, but should then avoid saving data until data has been successfully loaded from the file.
You don’t need to think about SQL-injections
You can encrypt/decrypt the JSON before it’s stored on disk or in the cloud. Passwords shall, as in databases, be hashed. Login attempts are tested against this hash, as done with databases.
Run one app instance, and have one JSON file for each customer. Make a specific sub domain or route for each customer, where their users log in.
What do you think?
How would this work for bigger SAAS apps?
Where goes the limit for data storage in memory?
The huge advantage with this style is that we don’t need the pain of moving data from a DBMS, with its own data types, to Kotlin, with different data types. Testing is easier, set-up is easier. I love this way of developing, but don’t know how scalable it is. Would love to hear your thoughts.