Open cjihrig opened 10 years ago
My only concern here is that we could end up saving the same default/fallback image in the database over and over again if we just use the default
field like we are now.
Maybe we can just store the string in a variable somewhere then. So when you GET
a record, you either get the base64 string from the database or the static string we have floating around the app somewhere. When you save into the DB, if the image is blank, just store a null
.
???
The more I think about this, the more I think it's fine to reuse the same image. That way, every employee has an image in the DB and the execution flow works the same way. Plus, images will be updatable.
I'm no longer so sure about this idea at all. After reading through the article linked above, I got to On Performance
section that states:
...when measuring the performance of hundreds of thousands of mobile page views, that loading images using a data URI is on average 6x slower than using a binary source link such as an img tag with an src attribute!
Damn. I didn't think it would be that big of a performance swing. The only other thing that is a pro to storing them as base64 is then you can decouple the database from the file system. If you store something in the database, are you basically storing a link to the file system somewhere. I guess we can leave it alone. The only other thing I can think of is like preloading images but we would have to look into how to do that.
Reopening because storing images in DB is not the same as base64 encoding them on the client. This will require more investigation.
Per Adam:
One thing you could try is rather than having it load the image (which creates a delay) just set the background image to be the base64 encoded value of the image from the server. That way, as soon as the response comes back, you can set the background image of the container div with that big number. Something like this. We should probably store the image in the database anyway and it would be easy to do as a base64 string.