Hey Guys,
So I thought I was beign fancy and instead of saving images to my server I converted them to base64 and stored them in the mongo. I thought this solution was awesome until I realized these cant be read by Facebooks graph.
My question is, is it feasible to create an API where i would call like example.com/img/idoftheimg and it would return the data of the image for display so it would be callable as such:
<img src="example.com/img/idoftheimg">
I’m assuming there has to be a way to do this and I was wonderingif someone had done something like this before I get started or had any reasoning why this would be a bad idea as opposed to just simply uploading the image.
I’m thinking i could just create a route that would get picked up serverside and return only the image data, but how do i convert the base64 back into the image data?
Hi @mikeacre,
I was/am working on exactly the same thing 
(Paused at the moment because of other issues…)
My thoughts so far:
- integration of the upload/image in any wysiwyg-editor will be hard (I would like to use TinyMCE or FKEditor)
- images will not be cached client-side
- all image calls will have to be handled by both Meteor and the DB (and, not being cached, this could lead to a lot of traffic/CPU
I tried to find a package/OSS project that was working this way, and so far found nohting.
But I guess it could be done…I would love to have my images on the same server. (For now, I am using a separate Joomla to host my images, but… shudder… But i need to be able to upload images on the fly, and have not found a easily implemented solution inside Meteor with a nice GUI a can give to a client.)
So: I would love to think/work with someone on this
Regards,
Paul
Just my two cents having worked with b64 images a bit:
They work pretty well for smaller sized images (under say 250x250px), but once you get into larger images, you’ll start to see performance issues in browsers… Also, as @pwiegers pointed out, there is no caching, so if you’re creating image-heavy apps, you’ll see that as a performance hit as well.
Depending on your setup, this could also add quite a bit to whatever data bundles you are sending over the wire (vs parallel loading of assets from a cdn, etc).
Unless you are working with thumbnails and have a legit use case for b64, it sounds like you are looking to implement a complex solution on top of a shortcut, instead of just putting in the work up front to move away from b64.
There are some good solutions for s3 in Meteor and they can hook in pretty easily to a modified plugin/extension in most editors. That would definitely be my suggestion.
1 Like
Hey Paul!
I’m using summernote:standalone as my wysiwg editor atm… I’ve had some small issues but it actually does the base64 image integration as a default… its kind of where i got the idea from. I also think this may be benificial in the future for machine learning purposes… but as @vigorwebsolutions said it may be best just to use s3 and I think i am just going to do that.
The second best alternative will be to store them in a separate folder on the same server, but it may be simpler in the long term just to keep them in s3.
I’d def be interested in a possible collab on a meteor project however send me a PM.
@vigorwebsolutions … do you think there is an added benefit to storing images as base 64 for machine learning purposes? I also thought perhaps it was easier for it to simply pull the image direct from the db rather than have to get the location form the DB and then get the image. But the caching is a good point…
If you are storing b64 in mongo, that’s really all you are doing: putting data into mongo and then asking for it back. There wouldn’t be any added benefit vs storing any other type of data in mongo and then querying for it.
Unless you had some weird situation where round trips to your assets’ servers were incredibly slow, I can’t really think of a strong use case for b64.
I don’t think S3 is the only solution, but in general it is pretty quick to implement and extend from. Something like imgix coupled with an S3 bucket is pretty powerful, imo. Plus you can easily add cdns, set up lambdas for transformations, etc.
I think if b64 was a reasonable solution in more situations, it would be more prevalent, but inspect the source of your favorite, performant websites and I think you will struggle to find an example of b64 in the wild.
1 Like