Need Feedback on Designing Online Configuration With Nakama Storage

We’re slowly moving our backend functionalities into nakama, one of the thing that we already use is a config json file stored on s3, with version on its storage path
say that


would have different contents with


the json itself is roughly 11kb size.
With contents roughly similar to this

    "generalConfig": {"startingMoney":10000, ..omitted },
    "boostersConfig": [{"name":"Blade","power":1, .. omitted}, {"name":"Spear","power":2, .. omitted }],
      .. omitted

We’re planning to break the json itself into storage collections based on version like this

    "collection": "1.1.0config",
    "key": "generalConfig",
    "value": "{\"startingMoney\":10000, ..omitted }",
    "collection": "1.1.0config",
    "key": "boostersConfig",
    "value": "[{\"name\":\"Blade\",\"power\":1, .. omitted}, {\"name\":\"Spear\",\"power\":2, .. omitted }],",

While on client side, we could just easily read storage by collection, this looks like it’s going to be trouble managing it in the long run, since the amount of collection would grow each subsequent version release

We tried condensing it into only one collection, storing all the contents of 11kb json on the value field, but on nakama dashboard we got http: request body too large error

Any suggestion on how to properly design online config with storage nakama?

While a large number of different collections is not a problem, a single collection where each key is a version of config sounds like a better model for your use case. The size limit you’re hitting is configurable have a look at the console.max_message_size_bytes option, which defaults to 4096 bytes. Note that the limit is for data sent/uploaded to the console, it’s not a limit on storage objects, so it’s safe to increase as you need.

Alternatively you can look at storing your configuration in code - embed the JSON data in variables/constants in your module code and allow clients to read it by calling an RPC function.

We’ve used both patterns very successfully so it’s just a matter of choosing which suits your use case best.