Skip to content

question: local images generation + remote CDN (combined) #819

@codenomnom

Description

@codenomnom

Hi @ascorbic, thank you very much for this library! It's been extremely helpful to me.

I've stumbled upon a situation in our latest project, and I wanted to ask a question before I dive deeper. I'm trying to create a reproduction repository, but let me settle my requirements first:

  • I want to use both local photos, and ones provided by Unsplash
  • Unsplash photos would be hotlinked, meaning I will use the API to fetch an appropriate URL for my photo, and then use unpic to properly figure out the best URL based on some configuration and display that photo from their CDN
  • In case of local photos, I would like to make Astro generate those, based on some configuration, and provide them as-is in the final build, meaning I don't want a dynamic image optimization that would require backend runtime in order to server them. I'd like to be able to host somewhere statically at some point (and not pay Vercel a bag of money for photos 😅 )
  • I have a few different types of images - one is cover, with its specific breakpoints configured, and others are "regular" where they should fit into the global breakpoints, but might require other sizes eventually
  • Ideally, a blurred placeholder would be available for all of those

What I've tried and what worked (or didn't):

  • I've successfully installed the packages and displaying Unsplash's photos was perfect - unpic successfully handles urls and edits them based on my breakpoints configuration
  • Blurred placeholders work like a charm for those images
  • Couldn't adequately setup the Astro image server - doing so makes the local images dynamic, meaning even in production they're served through the image endpoint, and not created buildtime
  • Using only the Image component (and not the service) is working great for remote images, but I need to handle additional logic for local images, use the different Image components, and end up with tons of generated sizes locally. I guess it somehow messes up sizes configuration as some images have same sizes but different files. Astro seems to be unable to dedupe the usages and thus creating new ones for each

I ran into some rabbit hole of fallbacks, sizes, cdn options and what not. As said - I will try to provide a replication repo, but I'd like to know if it's even possible to achieve something along those line:

  • Provide photo "asset" as strings - either remote ones (Unsplash ids) or local ones (file names). I have a mechanism to know which is what, but the format is plain string (Unsplash url or local image location).
  • For both cases I'd like to use the same breakpoints and widths/sizes for those photos
  • I'd like to have Astro generate versions of each local photo that I'm using, build time, then serve them statically (no Vercel image service)
  • Have a Picture/Source that defines all my versions so that the page loads the best one based on user's browser width
  • Use only one component to display those photos - adding if-elses all over the place is tiresome and if unpic's Image/Source could handle local ones statically, that would be perrrfect! I think this is my major question - can that happen, or it always relies on a dynamic image service?
  • I'd like to host this on Vercel if possible
  • Having blurred placeholders would be worth a bag of beers 😁

Thank you upfront!


p.s.
Okay, my understanding now is that if I use the image service (which handles Unsplash urls and placeholders), even local images are treated as dynamic and are not generated at build time. Is this assumption of mine correct? And there's no way to enforce build time generation? So basically it's either or - remote images with proper CDN modifications and placeholders using unpic, or local images and no placeholders using Astro's assets. Isn't there any way we can combine the best of both worlds? 😅

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions