I’m not going to try to mince words – in their current state, DataStores are garbage. They’re difficult to use, tedious to use, and are super unreliable. Let’s analyze each of these issues:
#DataStores are confusing:
DataStores have a significantly higher learning curve than anything else on ROBLOX. It’s not as simple as “Save this for the player” and “Load this player’s data” – DataStores involve handling data server errors, managing request limits, maintaining a cache, and building up and executing a request queue. This level of complexity makes using DataStores confusing, and has resulted in a plethora of DataStore questions from even ROBLOX’s most notable developers on the developer forums.
#DataStores are tedious:
DataStores are entirely unusable in their vanilla state unless you want to deal with hundreds of PMs regarding data loss. Every single developer on ROBLOX looking to use DataStores has to implement some sort of DataStore interface just to be able to use them, which has resulted in developers re-implementing the same thing as other developers over and over. There are likely thousands of DataStore interfaces developed by different individuals for their own projects that do exactly the same thing, and there will no doubt be thousands more in the future.
DataStores are unreliable:
To the small number of people who have made it this far, congrats – your reward is: data loss. Even after all of the hard work expended to get past the previous two obstacles, the developed DataStore interface will not be perfect. It will have some sort of flaw that you won’t find out about until, you guessed it, hundreds to thousands of players have lost data. No matter how much time and effort is spent developing amazing DataStore interfaces, there will always be bugs, and this leads to an untrustworthy and unreliable relationship between developers and DataStores.
#What is the solution?
In order for DataStores to be simple to use and reliable, they need to automagically work. This means making the cookie-cutter DataStore interfaces that have to be re-implemented over and over part of vanilla DataStores. DataStores should automatically compensate for data server errors, should not have request limits, and should automatically use a cache & throttle requests. When developing DataStores, ROBLOX likely came to the conclusion that they couldn’t have something that was both easy to use and powerful, but that is definitely not the case. Below is an implementation which both preserves the existing power of DataStores while at the same time making DataStores easy to use.
First, the existing methods of DataStore (GetAsync, etc) should not change. These are the backbone of DataStores that we leave exposed to preserve their power.
For making DataStores easy and possible to use out of the box, we duplicate the existing methods of DataStore and drop the Async suffix. These methods (Get, Set, Update, etc) would access the Async methods through an internal DataStore interface which automatically compensated for data server errors, and used a cache + request throttling (instead of saving to DataStores immediately, update the cache and then save every x seconds) to ensure the request limit is never reached. The only way requests could error and fail is if there was a coding error (e.g. attempt to index nil value) or the data was too large (trying to save 100 pages of text for instance). With this, DataStores would be usable out of the box, easy to use, and reliable. The issues concerning DataStores would be resolved.