Now that I'm super comfortable with sending stuff to S3 from a FileMaker database, I'm wondering what the implications would be of storing images by uploading them to S3 and then displaying them as text url which are displayed in a web viewer. I'm also aware some people mount s3 as virtual drives (or something) using plug ins, but I'm only interested in using URL's.
It would definitely be a boon with backups. I wonder if it would generally speed up the database, or perhaps containers are retrieved/display faster?
I'm pretty comfortable with getting images up and down. I'm super curious if anyone's been doing this for a while and can compare the experience for the end user vs using containers. Possible examples:
It's faster/slower
loading containers looks different/better/worse
It works great for display full size images, but less well for list of thumbnails
You can use S3 for FM container storage. A couple of long time FM devs have built tools to make this even easier. Scully from Mandlebrot Development has one at s3.fm that is pretty kewl stuff.
One thing this does solve, is the non-NIST compliant encryption of FM containers (for those people with NIST CMMC, or FIPS requirements for their data). Moving containers to S3 solves that compliance issue and - not from experience - I understand performance is outstanding.
It is definitely much faster, the images never touch the Filemaker container. You can drag a group of files and send them all at once. You can create time limited links to the files. You have unlimited space ( you just need to pay, but it is not fixed ). The FM server connection is not tied up while an upload or download is in process. You can setup the access in a webpage ( no web direct needed). Go through Jason's doc ( definedatabase ), very well done.
Lot of great responses on how to upload to s3, and the big problems that this approach addresses. What I'm interested in are the little gotchas that you find after 100's of hours implementation and 1000's of hour of user testing. Little issue you maybe didn't notice at first.
Example: consider a list view for a product table. Each product has a little thumbnail. You have a list view that's tall enough to accommodate ~50 records, and the user may be scrolling through a list of 1000's. I know users should find, not scroll, but users love to scroll long lists
The different approaches to storing images results in different user experiences:
Storing the thumbnail in a related table will prevent the user from smoothly dragging the scroll bar. FileMaker will insist on loading the thumbnails before it scrolls
Storing the thumbnail in the product table, while normally not ideal, allows FileMaker to scroll smoothly- the thumbnail containers will display a loading icon while it fetches the thumbail.
These scrolling/loading delays are a split second, but for a user working all day in this list, it makes a big difference (i.e. the second method is much better).
When I briefly tested this with s3 links, I was pleased to see that it had the smooth scrolling of the second approach. However it did not have a loading icon in place of the image. I'm not sure which my users would prefer, but I think the loading icon might be preferable.
Furthermore it seemed (I'd have to do more testing to be sure), that the container approach was faster with previously loaded thumbnails. In other words it seemed like those were cached (whereas the s3 links were not). That could also adversely affect the user experience.
Perhaps people have had luck using s3 for storing the main images, but stored list view thumbnails in containers. Just looking for the "10 things I wish I knew before switching my containers to s3">
