DEV Community

Cover image for simple-img microfrontend
Bryan Ollendyke
Bryan Ollendyke

Posted on

simple-img microfrontend

The previous integrations were hooked into web components as the way our frontend was talking to the microservice, but it largely worked in anything. These were much more built in a FaaS or Function As A Service way of thinking about their capabilities.

simple-img is different in that the micro is directly responsible for a very specific web component and the web component is intentionally engineered to require this microservice in order to perform it's function.

This element is mostly for prototype purposes 
and I've made it as part of our journey toward 
using things like this.
We might use this in production at some point 
(or opt into it) but currently do not have 
plans to leverage this specific tag.
Enter fullscreen mode Exit fullscreen mode


I come from a PHP / Drupal background (Drupal 4.6 whaaaat) in which we had an amazing monolith that could handle image compression and manipulation on upload. To manipulate images all you had to do was...

  • Run a bloated CMS
  • Install and configure the correct server packages
  • Allow for users to upload images
  • Run specific CMS modules that handle the upload and process using the server package
  • Leverage the CMS templating engine to hit the endpoints automatically to generate the derivatives
  • Never move off of the CMS or it all goes away

Now, this is a bit snarky but it's also true. If we wanted to compress and manipulate images, we just need never move away from the system that was providing that. I thought though, as we moved away from monoliths, was there any way that we could gain image manipulation from a single entry way and make that functionality portable as we move in the future to other monoliths?



  1. easily understood or done; presenting no difficulty
  2. hiding complex functionality in order to optimize the user experience downstream

simple-img seeks to take common image manipulation / resizing requirements and make it so that a web component's API can talk directly to a microservice to make this happen. The Code pen referenced above illustrates the options in a live updating space but here's the registration to see the options currently supported.

  // imgManipulation
    endpoint: "/api/services/media/image/manipulate",
    name: "@core/imgManipulate",
    title: "simple image manipulation",
    description: "scale, resize, convert and perform operations to manipulate any image",
    params: {
      src: "image source",
      height: "height in numbers",
      width: "width in numbers",
      quality: "0-100, jpeg quality to reduce image by if jpeg",
      fit: "how to crop if height and width are supplied (",
      watermark: "SRC for an image to watermark on the output",
      wmspot: "nw,ne,se,sw for moving the location of the watermark",
      rotate: "",
      format: "png, jpg, gif, webp",
Enter fullscreen mode Exit fullscreen mode

Simple image is a great example leveraging web components to directly interface with a microservice in a way that makes the "microfrontend" relationship completely decoupled from any library or framework. simple-img is built on a Vanilla HTMLElement base class, though it does have dependencies on MicroFrontendRegistry so it's not dependency free but weighs in at 2.8kb .

Using sharp we can easily apply many common transformations to any image, including watermarking! Vercel's Edge network helps ensure we cache the result and a slight tweak to MicroFrontendRegistry via the MicroFrontendRegistry.url() method will give us a URL to request the image transformation so that it can be leveraged in img tags as well.

Video breakdown

This was one of my favorite tags to produce in pursuit of this approach because it's something I've run into as a complicated problem previously. While sounding complicated, I hope the video breaks down how easy this was by comparison to how complicated what it's doing should be is.

Top comments (0)