Thanks S for the info.

Nick I think the API is going to be very useful and hopefully we can integrate it to improve the engagement and reading experience. Hopefully there this will prove more useful than suggesting articles to edit. It is already pretty good, If we can tune it even further to get better "reading" suggestions, it's going to be even more awesome.

I didn't know about the multiple titles, that's going to be useful for the Gather experiment we'll be doing for suggesting similar articles to add to a collection. Thanks.


On Tue, Jun 2, 2015 at 12:16 AM, Gergo Tisza <gtisza@wikimedia.org> wrote:
On Mon, Jun 1, 2015 at 1:57 PM, S Page <spage@wikimedia.org> wrote:
I'm not sure if there's any reason to interpose gettingstartedgetpages instead of querying search directly for morelike:pagetitle, it might cache stuff in Redis. The mobile apps might get better "Read more" suggestions using one of these.

At a glance, Redis is only used for caching category contents (ie. not at all when the morelike option is used). Anyway, if the concern is frontend performance, then requests should be cached in Varnish (otherwise the request has to travel to the data center, spin up a PHP process, load MediaWiki etc. so it's going to be slow even if all the API module does is fetch a value from cache), and that can be done for any API module via (s)maxage [1].

OTOH there is a good reason not to use gettingstartedgetpages, namely that GettingStarted is not installed on most WMF wikis.