1

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.

Improve this question

1 Answer 1

Reset to default
2

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.

Improve this answer
2
  • 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
    Commented 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.
    – Scant Roger
    Commented Jan 15, 2016 at 5:23

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