Theoretically, what speaks against JSON for storage?

I’m on my way building a framework right now and I’m asking myself if there’s anything speaking against using JSON files as storage for player variables.

I mean I would manipulate the player data in the server script and read from json on resource start and write to json periodically and on server end, no multiple JSON accesses ever.

Obviously I could simply go for mysql but I’m kind of trying things out that haven’t been around much and that sounded like a cool idea having a local storage for data.

Using a full-fledged database like MySQL will scale easier once you get a lot of data, for both querying (indexes are fast) and committing data.

It will also allow easier maintenance and ensurance your data is always stored, using transactions.

If you don’t want to use a database server you might as well use SQLite or KVP, they are both still very fast and provide data ensurance.

1 Like

I TOTALLY forgot about KVP, but aren’t KVP stored on the client and/or fetchable from the client side?

With SaveResourceFile() at least, I know that if I don’t include the json in the manifest, the client has no knowledge of 'em (I could be completely wrong about all this though)

There’s both client and server KVP

1 Like

Am gonna try that out then, thanks for the suggestion!

1 Like

Though, couldn’t the client still retrieve said server KVP if using StartFindExternalKvp()?

While they are the same functions, client KVP is stored on the client and calling the KVP natives on the server stores it in a folder in the server data folder. They have no relation to eachother.

1 Like

There are some examples in the cfx-server-data repository too, including a player-data resource for storing user data with KVP, and a money resource implementing it.