Shields: Any objections to deprecating the raster badges?

Created on 27 Feb 2019  Â·  15Comments  Â·  Source: badges/shields

Shields was founded to produce SVG badges which look really good, though it's long kept the ability to generate raster badges. However, the functionality requires a fair amount of work to maintain, is CPU- and time-intensive, and is probably not very useful.

I suggest we consider removing support for raster badges.

Another option would be to move out raster badges to their own microservice. It would simply fetch an SVG badge from Shields, and then rasterize it. That way the complexity can be completely removed from this codebase, and if there are performance issues they will only affect other raster users. It could be at png.shields.io or something like that.

What to do with these requests? Some options:

  1. Redirecting to static PNGs that say "raster badges are no longer available".
  2. Sneakily redirecting to the .svg equivalent. This should "just work" for readmes, websites, and the like. It'll be a unexpected if someone fetches a raster image manually from img.shields.io, though I think if we documented this behavior we'd be okay.
  3. Redirecting to a raster service running on a different domain.

Also, a process for getting community feedback on this decision:

  1. Add a deprecation notice on https://shields.io/ linking to this issue.
  2. Gather feedback for 30 days.
  3. Make a decision.
core

Most helpful comment

Sensible reason for supporting raster: embedding badges in emails. The Gmail image proxy, most notably, chokes on SVGs.

All 15 comments

This is the CDN's content-type breakdown for the last month:

Type | Requests
-- | --
svg | 280,896,691
empty | 23,300,961
json | 5,899,672
png | 2,481,242
html | 552,030
other | 474,690
gif | 234
javascript | 210
css | 74
plain | 1

I'm not sure those results are reliable. (What are these javascript requests through the CDN?) It might be good to add some onboard stats for this, along the lines of #3093. That said, it seems safe to say that gif and jpg are not really needed.

Debugging flaky raster tests, one example of work this feature costs us: https://circleci.com/gh/badges/shields/43861

Agree we can dump gif and jpeg without too much ceremony. Although png usage is small proportionally, ~2.5 million requests per month is definitely a non-trivial number. I think we do need to collect feedback to form an opinion on this. If a bunch of people all appear and say "I am using png badges because [insert sensible reason]", that is important to take on board.

Sensible reason for supporting raster: embedding badges in emails. The Gmail image proxy, most notably, chokes on SVGs.

That makes sense. So maybe the rasterizing proxy is the way to go. It makes things slightly less convenient for self-hosting users who might need raster badges, though it wouldn't be hard to self-host the rasterizer.

Given this is a feature that has real but relatively obscure use cases, the simplification and performance benefits make it seem worth breaking this out.

I've done some work on the rasterizing proxy, though running into some issues, in particular getting the badge render to work reliably on my Mac. I'm thinking about reworking it to use Puppeteer instead of imagemagick. It might be more reliable…

slack doesn't do svg well. hate to lose the png on self hosted behind my firewall

I've gotten a working version of the rasterizing proxy. It's deployed here:


https://raster.shields-server.com/badge/foo-bar-brightgreen.png


https://raster.shields-server.com/npm/v/gh-badges.png

The code is here: https://github.com/paulmelnikow/svg-to-image-proxy

Curious for feedback!

I think the next steps would be:

  1. Move the repo into the badges org.
  2. Pick a domain under shields.io where this service would be hosted. (e.g. png.shields.io or raster.shields.io)
  3. Deploy it, and make sure other people have access to deploy.
  4. Update the main server to redirect the .png badges to it, and remove the raster capability and its dependencies from the main server.

By the way, with our current usage 2.5M invocations will cost about $1/month (or less if the downstream cache handles a chunk of the load). I'm not sure how much execution time we should expect. I doubt the cost will add up but if it does we could reach out to Zeit about a donation.

Nice. I've had a bit of a play with the proxy. Seems great. I'm in favour of this as a way forward.

Swell. I've moved the repo: https://github.com/badges/svg-to-image-proxy

I'll set up the Zeit Now integration so merges to master will automatically deploy.

Any preference on the hostname?

Any preference on the hostname?

Names are always so hard 😄 Are you thinking about putting this on a subdomain under shields.io or a separate domain entirely?

Under shields.io, I'd say.

Under shields.io, I'd say.

That'd be my vote too. Maybe something short like str.shields.io? (svg-to-raster)

raster.shields.io is good with me :+1:

I've started the process with raster.shields.io.

Let's wrap this up in #3631.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

calebcartwright picture calebcartwright  Â·  3Comments

techtonik picture techtonik  Â·  3Comments

bruno-garcia picture bruno-garcia  Â·  3Comments

PyvesB picture PyvesB  Â·  3Comments

najeeb-ur-rehman picture najeeb-ur-rehman  Â·  3Comments