I am building a community website with a NodeJS express backend and a mysql database. Now I am up to the point where I want to store profile pictures of users and pictures related to specfic questions. I googled a bit and found many ways how to handle image upload, but I still have problems to figure out how and what to store regarding the location of the image.

I was thinking about creating a key-value store or a database table with a generated UUID as the key and the location of the image on the server (e.g. /images/user/123/profilepic/bla.jpg) as the value. This way I could store the UUID in the database (for example in the table user as profilePicId) and handle all image requests the same way, just by asking for the image with a certain UUID.

Using this method, the process would be like the following when client wants to get user info + profile pic of a user:

  1. Do get request to get user a object (firstname lastname, picUUID).
  2. Do get request on the api /file/{picUUID}
  3. Server > check key-value store what location is assigned to UUID and return image
  4. Put the apiUrl/file/{user.picUUID} address in an image tag's src and done :)

Am I on the right track here or what would be your take on this? I guess that this problem has been tackled many times. I am therefore also pretty stumped that there is not much information about this topic.

1 Answer 1


If there's only ever one image per person, you may not need a separate image data store. You could store the path with the user. Keeping it separate doesn't hurt, or course.

Regardless of how you store it, I would simply return the image path as part of the user "profile". /api/userprofile/id might return:

    name: "Honey Boo Boo",
    favoriteColor: "plaid",
    imagePath: "/images/user/123/profilepic/bla.jpg"

Then it's a one step process to bind the profile data to a view versus a secondary request to fetch, bind, and resolve the image.

  • Thank you for your comment Scant. This was also my first idea but I also need to store other images (related to choices that users make). This amount will (hopefully) increase very fast. If I would follow the same idea for these images, would that not create a performance burden on the server + exposure to security issues? The way I fixed it now, is by using the key-value store. Do you see any drawbacks using this method next to increased complexity?
    – Bram
    Jan 14, 2016 at 13:30
  • @Bram There's also an extra server operation per render cycle: return id, call api for path, merge path into view, retrieve image from server -- versus: return path, merge path into view, retrieve image from server. I would start with your current approach. Measure load. If it gets to be too much, aggregate data where it makes sense. Jan 15, 2016 at 5:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.