Cache results of external APIs about feeds.cocoapods.org

[alloy]

Not atm, but when we move to Heroku that’s an option.

[alloy]

I was also thinking for the HTML page: why not just do it in JS from the page at the time it’s needed? And could that also work for the RSS HTML feed?

[fabiopelosin]

I was also thinking for the HTML page: why not just do it in JS from the page at the time it’s needed?

I didn't implement it in JS to avoid hitting the GH API limit as the request should be authenticated (60 requests per hours per IP)

[alloy]

True. But would a client reach that limit?

Regarding caching, you can do that with HTML5 Web Storage? http://www.html5rocks.com/en/features/storage

[fabiopelosin]

True. But would a client reach that limit?

Unlikely by just visiting the page... but it might be the case if the client did other requests in that time frame. I picked this solution as it looks more robust (also github.com mobile doesn't show the stargazers count unless you're logged in, I think exactly for this reason).

[alloy]

I picked this solution as it looks more robust

But less up-to-date and with added complexity.

also github.com mobile doesn't show the stargazers count unless you're logged in, , I think exactly for this reason

I would think that’s because making a lot of useless network requests is not something you want on mobile.

[fabiopelosin]

I picked this solution as it looks more robust

But less up-to-date and with added complexity.

Good point about being up to date... regarding the complexity I think this is approach simpler because we are not mixing rendering on the server with dynamically performed one via JS (but I recognise that my experience in web apps is not exactly at the expert level).

also github.com mobile doesn't show the stargazers count unless you're logged in, , I think exactly for this reason

I would think that’s because making a lot of useless network requests is not something you want on mobile.

Good point, but fetching the stargazers count, at least to me, is not an useless network request. Also if the rationale is to save bandwidth, I don't see why the behaviour should change according to wether you are logged in or not.

[alloy]

regarding the complexity I think this is approach simpler because we are not mixing rendering on the server with dynamically performed one via JS

The idea would be to only do this in JS if it’s also usable in the RSS feed, in which case we don’t need any server-side handling of such statistics anymore.

Also if the rationale is to save bandwidth

I guess it would be related to making many requests, which are costly operations.

I don't see why the behaviour should change according to wether you are logged in or not.

Good point.

But actually I’m not sure why it would be related, because they don’t even need to use JS and the API, they can just include it during their response rendering. (That’s of course not to say that they might still be using JS and the API.)

Maybe it’s some UI/UX thing in that possible non-GitHub users browsing a repo don't get to see stats that might be foreign/useless to them?

[fabiopelosin]

The idea would be to only do this in JS if it’s also usable in the RSS feed, in which case we don’t need any server-side handling of such statistics anymore.

Can you run JS in an RSS feed?

But actually I’m not sure why it would be related, because they don’t even need to use JS and the API, they can just include it during their response rendering. (That’s of course not to say that they might still be using JS and the API.)

Dogfooding? It is just a hunch but I don't think that the mobile app uses the same pipeline of Github on desktop (for example is missing notifications, which I consider one of the main reasons to visit github.com)

[alloy]

Can you run JS in an RSS feed?

I have no idea about RSS :D

I was just thinking that if HTML is allowed, then maybe JS is as well.

Dogfooding?

Maybe indeed.

[fabiopelosin]

Regarding RSS, it is not possible: http://stackoverflow.com/questions/2599443/javascript-inside-rss-file

[alloy]

I don’t think those answers necessarily apply. It simply seems to be an undefined thing. Because HTML is allowed in the RSS spec (http://cyber.law.harvard.edu/rss/rss) so I could see some clients also doing JS. But again, I have no idea :D

[fabiopelosin]

It simply seems to be an undefined thing.

This is one smell test for me to avoid a solution.

There is just one thing that I know about RSS and that thing is that every client is different... They are much less consistent than browsers, so I'm pretty confident that a non negligible part of them doesn't support JS. Also I've never seen it being used in an RSS.

There are many wonderful uses of JavaScript on the web today, used for everything from simple form validation to AJAX techniques. JavaScript on your own web site is perfectly appropriate and typically quite safe. Unfortunately, JavaScript in the contents of RSS feeds is problematic and dangerous. Some nefariously clever uses of JavaScript have been demonstrated in the security community, the worst of which steal data on a user's local computer and upload it to a server.

A number of security bulletins have been issued about JavaScript-based security attacks in RSS feeds in the past year. Accordingly, developers of RSS readers are ensuring that their applications strip out or disable any use of JavaScript in an RSS feed. Because of these problems, you should not attempt to use JavaScript in any part of your RSS feed.

From How to Build an RSS 2.0; Feed O'Reilly Media, Inc; 2006

[alloy]

Yeah I agree with you. Too bad.

[kylef]

I think this just needs to query metrics.cocoapods.org.

[segiddins]

I think we can close this out now.