Shields: Announcing the Endpoint badge (beta)

Created on 22 Jan 2019  ·  21Comments  ·  Source: badges/shields

service-badge

Most helpful comment

All 21 comments

Good work on shipping this :+1: I think this really opens the door to more of a "plugin" style architecture - users will be able to enjoy a wider range of more esoteric integrations and use-cases without us necessarily having to host a service integration in core for every single programming based service under the sun.

Sorry I didn't get a chance to raise this at the review stage, but one thing that I think is likely to be a point of confusion is the cache key. I think some users will try to set it to 0 and get unexpected results. It would be useful to more clearly communicate that there is a floor on the cache length (but as I remember it, its a bit fiddly to surface the value because the variable isn't set when we build the front-end). Is there a way we can more clearly communicate this in the docs?

Sorry I didn't get a chance to raise this at the review stage, but one thing that I think is likely to be a point of confusion is the cache key. I think some users will try to set it to 0 and get unexpected results. It would be useful to more clearly communicate that there is a floor on the cache length (but as I remember it, its a bit fiddly to surface the value because the variable isn't set when we build the front-end). Is there a way we can more clearly communicate this in the docs?

Yea, good shout.

The Endpoint service has its own floor of 300 seconds that's defined in the service, independent of anything that's configured at runtime. At least that's how I _think_ it's implemented. (That work went on a while so TBH I don't completely remember.)

This is what I wrote in the docs:

screen shot 2019-01-22 at 3 47 59 pm

I agree it's not totally clear; it doesn't mention the 300-second floor at all.

Nice work on this, I can definitely see this badge being used regularly.
:+1:

I tried using it before reading the docs or PR, just to see how easy/hard it would be to use.

And one of the things i found strange was that colorB is set using color, colorA using labelColor and logo using namedLogo or logoSvg.
Do you think it would be better to keep these matched to the query paramaters we currently use?

Also when an unknown key is included (such as colorB), the badge would result in:

I feel like it would make more sense to just ignore these keys?

Edit:
Some random badges using the endpoint badge:
(NZ time)



_(doesn't show the json response if not requested by shields)_
← _(wont show unless it is october)_

Was this page helpful?
0 / 5 - 0 ratings

Related issues

niccokunzmann picture niccokunzmann  ·  3Comments

chadwhitacre picture chadwhitacre  ·  4Comments

kerolloz picture kerolloz  ·  3Comments

salaros picture salaros  ·  3Comments

calebcartwright picture calebcartwright  ·  3Comments