Proposal: Profile Pictures

[zbarnz]

Context

Most work management web applications have some form of profile system with user avatars. These avatars almost always have the capability to hold a user uploaded profile picture. Our app should have this ability as well. Especially with it's emphasis on user contribution, associating contributions with a face rather than a name will bring an extra level of sociability to MeetingMinder.

Implementation

Summary

Most of the data handling of a user's avatar will be straightforward. Images, however, are more complex to transmit and store. Uploading images requires a lot of time and bandwidth as does re-serving images to users from our database. Although we cant avoid having to upload images from the user, we can avoid having to store and pull this data by using image references. Instead of storing images ourselves, we can push these images out to an API and get a reference URL. There is less overhead serving images directly from a web server versus going through an application server and database server for every request.

Required libraries

• @google-cloud/storage

Google Cloud Storage

The way we will store these image files is inside of a Google Cloud Storage bucket. Luckily storage is very cheap at $0.02/GB per month with no retrieval fees for standard storage. After uploading an image from MeetingMinder to our bucket, google will send back a JSON object with the image url which we can store in our database.

UI

References:

• Basic Implementation
• Cloud Storage pricing
• Storage Classes
• MongoDB image storage thread

[thudsonbu]

This is gonna be awesome 🚀. Just a few considerations:

Your definitely right about storing not storing images in the database. Storing a reference is a much better idea. We just need to make sure that the blob store and the database don't diverge which can be difficult. We will also want to make sure that the image size is reasonable.

In regards to fetching, hitting the storage buckets urls is probably sufficient given that these images will be small. But just for fun, can you check and see if we can use a CDN on the cheap? That could result in a significant performance improvement over fetching from the bucket directly.

We should also be transparent about the fact that these images will be publicly available (which is true for most applications but they don't tell you). We will need to allow unauthorized access in order to fetch using the urls provided by GCP from the client (I don't think we want to proxy these images through the web and api servers just for auth). The upload should obviously go through the web and api servers for auth and so that we can coordinate the saga for uploading the blob, deleting an old blob, and updating the database using a single machine.

Does all that sounds good? Also, can you make a rollout plan in terms of prs?

[zbarnz]

@thudsonbu Yeah that sounds good, can you explain what you mean by rollout plan?

[thudsonbu]

@zbarnz I mean a plan for how you are going to build out the feature. Ideally we want to merge little bits incrementally. That way there aren't merge conflicts and the surprises that come with a big launch.

[zbarnz]

Avatars stages

Stage 1: User Avatars containing initials and a random color like JIRA
Stage 2: Image upload to google bucket and storage on backend
Stage 3: Frontend implementation / authentication stuff
Stage 4: Adding user icons where necessary around the site

++ @thudsonbu @Dahvd