Open fyliu opened 1 year ago
I would rather store the images in a GitHub repo and then use the URL it creates. Reasons:
Example:
I am open to understanding why it would be better to let Django store it in an S3 bucket, if there is a reason. Please detail
My reasoning for suggesting ImageFields rather than URLFields for images was in part because ImageFields would allow you to more easily keep a copy of the image rather than referencing it in a location H4LA does not control. A repository for the images might be OK - depending on the file sizes and the total size of the repository. But I don't know of a django package for storing user-uploaded images in S3. I would expect it would be possible to find or write one.
@cnk 1 - we are not worried about the size of the images in the repo. It would be no larger than what is currently stored in the hack for la website repo, which works fine 2 - it would be nice if we could use Django to authenticate that people are uploading images of the correct dimensions and size, which would be a valid reason for having an image field rather than a URL field, unless validating the image dimensions and size is possible on URLs too?
Thoughts?
1 - we are not worried about the size of the images in the repo. It would be no larger than what is currently stored in the hack for la website repo, which works fine
Sounds like you expect similar data so this is probably OK to store in Git - especially with large file support. I suspect PeopleDepot will have more images/files because it is easier to upload from a JS frontend than it is to add the same file via a pull request but as long as the desired files are similar, that shouldn't be too big a deal.
2 - it would be nice if we could use Django to authenticate that people are uploading images of the correct dimensions and size, which would be a valid reason for having an image field rather than a URL field, unless validating the image dimensions and size is possible on URLs too?
Validation is more certain if you maintain control of the image via the same code that is doing the validation. If we use an image field, we can get Django to handle image upload and validation. One could do similarly by downloading the image from the url and then validating it. But I have less confidence that the image url will continue to point to the validated image file if that file isn't managed by django itself.
I do, however, urge you to consider the fundamental tradeoff in storage options - money vs time. If you use GitHub to hold your images, there is no hosting fee - but I am not seeing a django package that uses git as the file storage backend. If you use an S3 bucket or other backend supported by django-storages, file storage can be configured in an hour or so. Unless someone else finds a 'store django media files in git' package, it is going to take a lot longer than that to write the storage code.
@cnk @fyliu ok, then we will use Django and aws s3 bucket
Moving this to Questions. @bonniewolfe I vaguely remember discussing as a team and deciding that we're going to store the logo images in github and their urls in django for now? If so, we should close this issue or move it to the Ice Box if we want to reconsider it later, like after a certain deployment milestone.
We 100% do not want to pay for image transfers from AWS to our websites, if we can store the images in a repository and have the website access them on the build, we should.
Dependency
Overview
Suggestion from a PR review. The project image_logo field is a URL, but would be better managed by django.
Action Items
Discussion Items
Resources/Instructions
_Originally posted by @cnk in https://github.com/hackforla/peopledepot/pull/84#discussion_r985380281_