It's cool!

Could we put the number of followers on the right-hand-side of the badge though?

The main reason I created a new template and dropped the follower count is due to the API rate-limiting user lookup requests to 180 requests per 15 minutes. If this gets widely used, it will be fairly useless unless we make the caching more aggressive (something like 24 hours).

I'd welcome some suggestions on how to work around this (or maybe this is only useful for people who are running their own servers and will only hit the twitter API once every few minutes).

It's pretty simple to include both types of badges with the caveat that follower count might not always show up on the second one. Removing the follower count bubble when we can't fetch it is a more complicated task, but can be done fairly easily. I will throw together a new commit for the former.

Here are screenshots of both types of badges.

As requested:

And the original badge that doesn't hit twitter's API:

2249ae1 requires two properties to be added to the secret.json, twitter_consumer_key and twitter_consumer_secret, which can be fetched from the twitter dev center.

We can probably add graceful degradation such that when the twitter api keys aren't available it will only serve the badge without the follower count. Additionally, such behavior can be added in instances where the twitter API is rate-limiting the app.

For the time being however, I think this feature stands on its own.

The main reason I created a new template and dropped the follower count is due to the API rate-limiting user lookup requests to 180 requests per 15 minutes.

Yes, rate limiting is the bane of my existence. Intuitively, I would assume that, just like there isn't rate-limiting to the private Twitter URL API (in use in their badges), it wouldn't be there for the Twitter Follow badge either. Have you done any analysis on those? What is their limit?

curl 'http://cdn.syndication.twimg.com/widgets/followbutton/info.json?screen_names=gregcochard'

[{"following":false,"id":"366740708","screen_name":"gregcochard","name":"Greg Cochard","protected":false,"followers_count":33,"formatted_followers_count":"33 followers","age_gated":false}]

Headers (no obvious indication of rate limiting):

cache-control: must-revalidate, max-age=600
content-disposition: attachment; filename=json.json
content-length: 188
content-type: application/json;charset=utf-8
date: Tue, 13 Oct 2015 22:32:01 GMT
expires: Tue, 13 Oct 2015 22:42:01 GMT
last-modified: Tue, 13 Oct 2015 22:32:01 GMT
server: tsa_f
strict-transport-security: max-age=631138519
timing-allow-origin: *
x-connection-hash: 5fc792961271bbc9ac85d449684d0cba
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-response-time: 169
x-transaction: 3f856871df0672cb
x-xss-protection: 1; mode=block

It is really nice of you to have coded the Twitter API key-based authentication! It falls under the 180 requests per 15 minutes rate-limiting, is that right?

It is a cause for sadness, but it is easy to simply discard the right-hand side when we notice we hit the rate limit. What happens in that case that we may detect (to distinguish it from an actual error)?

Removing the follower count bubble when we can't fetch it is a more complicated task, but can be done fairly easily.

My thoughts exactly! We can change the social badge template to discard the bubble when there is nothing on the right-hand-side.

Do you want to add a commit to this PR that does this?

I'd like you to remove templates/twitter-follow-template.svg from e50f57f.

Sounds good. I'll remove the twitter-follow-template.svg and modify the social.svg template to only conditionally include the right-bubble if there's text to put there.

After all is good, I'll squash this into a single commit to remove references to twitter-follow-template.

Regarding the twitter badge API, I'm guessing it will not be rate limited, but we might fall victim to them shutting off that API since it's not documented. I'll take a look.

Looks like the CDN for their JS embeds is not rate limited because they know these endpoints will be hit from all over the web, unauthenticated.

We should be able to use this without issue.

Additionally, it appears that there's no case where the bubble would not be populated.

I updated the social template to have a nobubble variable, which when true will hide the bubble. You can use this in the URL as well, with &nobubble=true. I would like that functionality in certain cases.

I realized I left in the code to fetch the twitter bearer token. Would it be desirable to leave it in unused?

@espadrine Any further comments on this?

The work / play balance is so hard!

I realized I left in the code to fetch the twitter bearer token.

Well, dead code can't kill anyone! ☺

I'm not a fan of the nobubble query parameter. Most query parameters have meaning for any badge, and I'd preferably keep it that way. They have to be special-cased in the cache system, too.

Do you think it'd be ok to check whether badgeData.text[1] is empty from within the template, and not show the right-hand-side in that case?

I think you should change the SVG's computed width in that case.

I'm really excited about this change!

Any news? I can take over this PR if need be. I'll give it a week before I rewrite it.

I have been busy with work recently but I can make a push to finish in the next week. Definitely want this feature to make it in as well 😄

👍

@espadrine how does it look now? I haven't had a chance to test the changes since I'm having issues with canvas. Can you verify?

I'll take #568 if all is well with this change.

Thanks a lot! Looks fantastic. It's secretly live right now; I'll make one more fix before putting it on the main page tomorrow.

Thank you!