Sunset of Wikimedia recommendation API

by
Translate this post
Toropetsky District. Winter sunset in the field. Dmitry Makeev, CC-BY-SA 4.0

Executive Summary

We wanted to let you now that we will be removing the recommendation API from the current offerings some time soon after March 31st 2025. This API is no longer used by newer versions of the Wikipedia Android Mobile application, which was its sole user. The API in question is the one exposed under https://<project_domain>/api/rest_v1/#/Recommendation family of endpoints. Requests to it after the removal date will be returning an error. This change will only impact editors with old Android applications and utilizing the Suggested Edits functionality. We encourage these editors to upgrade to newer versions of the Wikipedia Android application.

Below, we provide more information as to how we reached this decision.

Forming a team

Starting early October 2024, the Wikimedia Android app stopped using this API and moved to a different way of obtaining the recommendations needed. This change allowed us to start a conversation with various stakeholders in the Product and Tech department. The problem was ensuring that we turn off this API responsibly so that we do not have a significant impact on users who have not yet upgraded their apps and do not waste  effort on supporting a service we are moving away from more than we need to. Three principal engineers in the Foundation, namely Jon Robson, Moriel Schottlender and Alexandros Kosiaris, formed an ad-hoc team to examine the situation, investigate a number of factors, reach out to a number of teams, come up with a recommendation and ensure it is agreed upon.

Remaining users

We made sure that old versions of the Wikimedia Android application were the sole remaining valid user of this API by examining past data. We estimated the amount of requests that would be impacted by the sunset action to around 2000 per day, which is a sufficiently low number of requests that we are happy with. We did not try to translate the requests numbers to actual humans, but it’s well below that as we expect more than 1 request per human per day. 

One thing we did witness during the process, was an increase in the number of non valid users, possibly scrapers and/or abusers. This is in line with anecdotal stories across the industry as well as patterns we ‘ve observed in other offerings. Needless to say, this type of usage poses risks to our infrastructure.

Maintenance costs

One of the factors that was looked into was maintenance costs. It had become apparent already that the code base powering the API wasn’t adequately maintained, receiving only occasional updates as ordained by our Operating System Upgrade Policy. This wasn’t a healthy sign as it required finding people ad hoc to perform the required maintenance tasks, whether that involved upgrading Node.js versions and libraries, or the underlying Operating System.

This cost was paid solely by the Site Reliability Engineering team, who in their mandate to own and maintain the underlying infrastructure and platform, help/push teams to perform these upgrades, had to  end up doing it themselves, despite lacking context and experience, to avoid blocking sustainability goals. The lack of context and experience created a lot of uncertainty in estimating this cost and planning for it.

Risks

We estimated the risks of keeping this ill-maintained service into our offerings. It became quickly clear that there are types of security incidents, whose likelihood increased with time (due to the limited maintenance), that would incur ballooning costs when they would materialize. To name a few, those would be anywhere in the range of a simple Denial of Service attack to a full compromise of infrastructure, all of them requiring eventually substantial response from the foundation and possibly the entire movement. Furthermore, the maintenance process itself incurred risks, due to the inexperience and lack of context the team performing the updates suffers from. Gaining that experience and context for an offering that had no valid users, was nonsensical. Another type of risk we wanted to estimate was the impact in other running projects of the foundation. It turns out that this sunset not only does not hinder any running project, but rather contributes to the RESTBase migration project.

Options considered

We did consider 3 different paths during our process. Not doing anything, sunset the API as soon as possible and sunset the API with an announced date after taking into consideration the above. We recommended the 3rd option and it was approved.

Thoughts on the process followed

The process followed by the three aforementioned engineers is called internally in the Wikimedia Foundation “Decision Brief”. As a process, it was useful, as it allowed us to understand the scope of the issue, gather sufficient information from related stakeholders and come to an agreement, using a ready made template. In the future, we hope that this will become more streamlined, allowing engineers of various levels to utilize it.

Benefits

  • The Wikipedia Android Application team will no longer be relying on a ill-maintained API, but rather more well maintained offerings, giving them the ability to invest into making the application better
  • The RESTBase migration project ends up not having to proceed with the migration of the API
  • The Site Reliability Engineering team no longer has to pay the cost of maintaining this service, allowing them to focus more on other projects. While there will be a cost for the sunset that will be paid by this team, the overall gains are expected to quickly offset it.

More info

If you are curious about how this may affect you or what the recommendation API is.

Thanks

Thanks to Jon who relentlessly pushed this forward, Moriel, Luca Toscano, Joseph Seddon, Dmitry Brant and Mateus Santos for contributing and Suman for reviewing and approving. 

Can you help us translate this article?

In order for this article to reach as many people as possible we would like your help. Can you translate this article to get the message out?