I'm going to specify what must do before going to production and what I would do right now.
The problem
There are 2 images we have to store:
- The user profile image
- The product profile image
When the user logs in using a social media, the identity provider returns a profile picture URL. I searched the internet and apparently everybody agrees that we should store the image, not use this URL.
Reasons:
- The provided URL might change or become offline and that can't affect our service.
- The user may not log in through a social network so we have to have a way to store the image anyway.
- For the product, we have to store the image anyway.
So we have to store the image.
What we must do before going to production:
Use Azure's file storage. It's possible to make it in such a way that we can access files stored in the storage through a public URL, which is exactly what we want. So, here's what we must do before going to production:
When the user logs in, if there's no profile picture for that user, we have to download the image from the social media URL, resize it and store it in the Azure file service, grab the URL and put that in the database.
What I think we should do now:
Start using Azure at this stage will require us to use the emulator to debug. I'm pretty sure that using the Azure emulator so early will SLOW us down throughout the next 5 months of development.
So, for that reason, I would create an IImageService with methods like
StoreProfileImageGetProfileImage
And I would create an implementation of IImageService that resizes the image and stores it on the database, in the user table and in the product table. When we're closer to release, we create a second implementation of the same interface that now goes to Azure, this way we can push the use of emulator for some months. We drop the columns by then.
I'm going to specify what must do before going to production and what I would do right now.
The problem
There are 2 images we have to store:
When the user logs in using a social media, the identity provider returns a profile picture URL. I searched the internet and apparently everybody agrees that we should store the image, not use this URL.
Reasons:
So we have to store the image.
What we must do before going to production:
Use Azure's file storage. It's possible to make it in such a way that we can access files stored in the storage through a public URL, which is exactly what we want. So, here's what we must do before going to production:
When the user logs in, if there's no profile picture for that user, we have to download the image from the social media URL, resize it and store it in the Azure file service, grab the URL and put that in the database.
What I think we should do now:
Start using Azure at this stage will require us to use the emulator to debug. I'm pretty sure that using the Azure emulator so early will SLOW us down throughout the next 5 months of development.
So, for that reason, I would create an
IImageServicewith methods likeStoreProfileImageGetProfileImageAnd I would create an implementation of
IImageServicethat resizes the image and stores it on the database, in the user table and in the product table. When we're closer to release, we create a second implementation of the same interface that now goes to Azure, this way we can push the use of emulator for some months. We drop the columns by then.