What is best way to store small amount of data in BE (literally 1 line)?

I am currently working on functionality where users wants to keep a single message in header of a page to notify others of something happening in system. Essentially a header that can be updated by any user.

As this header needs to be shown to every user in site I can't store it in local storage or user's table. Also this is a single line of message on a single page, so making a whole database table for this sounds utterly stupid. So to achieve this functionality for now I have added a json file in BE which just have this message in there and a view which allows users to edit this file. I have also placed this file in gitignore because data change in this should not reflect in git.

This system works fine for now, but when I redeploy using Docker this file is removed and rebuilt losing the initial message. Is there a better way to store and update this data? Or any way to not lose my data on redeploy?

userdata.json

{
   message: "Holiday tomorrow, please report any issues by 3."
}

Reading data in Django View

try:
    if not os.path.exists(USERDATA_FILE):
        # Create the file with default structure if it doesn't exist
        with open(USERDATA_FILE, "w") as file:
            json.dump({"message": "Hello World!"}, file, indent=4)

        with open(USERDATA_FILE, "r") as file:
            data = json.load(file)
except Exception as e:
     print("Error in reading data")

You should store this datum in your existing database, even if the overhead of writing a migration and table infrastructure seems excessive at first glance.

One critical reason here is that your Docker setup already has a database and it already has persistence. Adding local-file storage to a container comes with a mild amount of complexities, including managing filesystem permissions and separately backing up that file. Using the persistence store you already have takes this detail out of the system, and makes the whole thing easier to manage.

Relatedly, if you're ever looking at running multiple replicas of your system, having the banner be stored in a single database makes it easier to manage. If you deployed the container in Kubernetes, the persistence problem becomes harder (it's hard to get storage that's shared across container replicas); you could maybe inject it via a ConfigMap but you'd need to do Kubernetes-specific management to update it. You can also imagine deploying the application without a container but on multiple hosts for scale or redundancy, and there you'd need to copy the banner file to every host manually if it weren't stored somewhere centrally.

It's also easy to imagine setups where the same banner isn't shown to every user. Maybe you have multiple user groups, or multiple tenants sharing the application. If the banner is stored in a table then it's easy to add a migration to ALTER TABLE banner ADD COLUMN ... to add a group or tenant ID, but with your proposed file layout it's going to be trickier to change away from "show the same banner to everyone".

A typical best practice is to avoid mounting anything into your container, except configuration files if needed, and to avoid storing anything in local files. That would seem to apply here as well.

Back to Top