Figmage: I don't mess with images (2020)(heyraviteja.com)
heyraviteja.com
Figmage: I don't mess with images (2020)
https://heyraviteja.com/post/projects/figmage/
8 comments
Whoa, this is brilliant and solves a very real problem.
Lots of wasted time. Makes me happy every time I use it
Hey HN, I built Figmage as a Figma plugin because I was super frustrated with managing images and creating image assets every time I wrote a blog post.
Figma is a great tool to design and manipulate images from cropping, resizing, adding annotations, and making cover graphics, and you can export them. So Figmage gives a shareable link to your designs that live in Figma.
Updating your design in Figma, and publishing, will update the images everywhere they're referenced. That means no re-uploads, and re-deploys.
Figma is a great tool to design and manipulate images from cropping, resizing, adding annotations, and making cover graphics, and you can export them. So Figmage gives a shareable link to your designs that live in Figma.
Updating your design in Figma, and publishing, will update the images everywhere they're referenced. That means no re-uploads, and re-deploys.
"It’s the most tedious part of making websites and writing blog posts."
This is great in that it is exactly the opposite for me. Manipulating images is what I enjoy. Writing text is like pulling teeth only after getting the root canal. I'd rather manipulate pixels any day!
>Updating your design in Figma, and publishing, will update the images everywhere they're referenced. That means no re-uploads, and re-deploys.
This is very intriguing. Link rot scares me, but I guess it's no more of any issue than any other 3rd party image hosting. Nice one!
This is great in that it is exactly the opposite for me. Manipulating images is what I enjoy. Writing text is like pulling teeth only after getting the root canal. I'd rather manipulate pixels any day!
>Updating your design in Figma, and publishing, will update the images everywhere they're referenced. That means no re-uploads, and re-deploys.
This is very intriguing. Link rot scares me, but I guess it's no more of any issue than any other 3rd party image hosting. Nice one!
I greatly sympathize with the author's dislike of dealing with images. I'm still waiting for an inexpensive image hosting & manipulation service that I can push images to at massive scale, get N variation images back (from a source image) along with links for the images to then be placed within my service (along with some primitive image transformation options, nothing too fancy).
I absolutely hate dealing with hosting and managing images for services I build. I've yet to find anything remotely cost-practical that rides on top of eg AWS or the equivalent and just provides a simple thin layer service so I never have to store or manipulate images again. Take AWS, add a modest margin on top for the image management & manipulation layer. I've been waiting for someone to do this for 10-15 years at this point. Perhaps either there's no great business there (not enough potential customers interested in having image hosting managed away), or everybody else hates dealing with image hosting too.
Companies like Cloudinary offer such services, and their prices are obscene (eg $100/month for 225gb of bandwidth and storage).
At some point I'm going to just have to build it myself, get into the image-hosting-as-a-service business because I hate image hosting so much.
I absolutely hate dealing with hosting and managing images for services I build. I've yet to find anything remotely cost-practical that rides on top of eg AWS or the equivalent and just provides a simple thin layer service so I never have to store or manipulate images again. Take AWS, add a modest margin on top for the image management & manipulation layer. I've been waiting for someone to do this for 10-15 years at this point. Perhaps either there's no great business there (not enough potential customers interested in having image hosting managed away), or everybody else hates dealing with image hosting too.
Companies like Cloudinary offer such services, and their prices are obscene (eg $100/month for 225gb of bandwidth and storage).
At some point I'm going to just have to build it myself, get into the image-hosting-as-a-service business because I hate image hosting so much.
Honestly, I think this is solvable with a Lambda that's run on S3 upload. Upload your originals to an input directory, then the Lambda runs the transformation and writes it to an output directory.
Imgix.
Great idea. Bought immediately, this has always been a pain for me
Thanks so much for the support!
Great idea! I wish I could provide an imgix api key and use it with this, because we need to use our own CDN for images. But this would take a lot of hassle out!
You probably could, does your CDN have an API? Or is imgix a CDN. I could check if it’s doable.
Imgix is a cdn!
Can you serve images directly from S3 static website hosting? You’ll avoid any cold start (and Lambda costs) that way. You could also put CloudFront or Cloudflare in front for caching after the first request.
Good suggestion. I definitely could! I haven’t had a bunch of demand to really optimize that right now. It would also save any time spent for the lambda function executing.
As someone who has operated an image hosting service, few more suggestions.
1. Use proper cloudfront caching. I see that all images are hitting the origin every time. Its adding more latency to the request.
2. Set proper cache headers.
3. Fix www.figmage.com. Don't put https in DNS. LOL
4. Enable IPv6 in cloudfront.
1. Use proper cloudfront caching. I see that all images are hitting the origin every time. Its adding more latency to the request.
2. Set proper cache headers.
3. Fix www.figmage.com. Don't put https in DNS. LOL
4. Enable IPv6 in cloudfront.
I made an open-source service [1] that does the same thing earlier this year. Although it's pitched for OpenGraph images (where I share OP's pain when dealing with blog post assets), it works for any kind of image, by proxying the Figma API that renders a frame to an image and returns an S3 public URL.
[1] https://usefoggy.vercel.app
[1] https://usefoggy.vercel.app