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.
- Codepen demo with tag
- Demo (add an image to the input field)
- npm install @lrnwebcomponents/simple-img
- microservice source
- web component source
Disclaimer
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.
Scope
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?
Simple
ADJECTIVE
- easily understood or done; presenting no difficulty
- 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
MicroFrontendRegistry.add({
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 (https://sharp.pixelplumbing.com/api-resize)",
watermark: "SRC for an image to watermark on the output",
wmspot: "nw,ne,se,sw for moving the location of the watermark",
rotate: "https://sharp.pixelplumbing.com/api-operation#rotate",
format: "png, jpg, gif, webp",
},
});
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)