Page MenuHomePhabricator

[5.3.3 Epic] Productionize the MVP of Attribution API
Open, Needs TriagePublic

Description

Based on a MVP, harden and refactor to provide a production-ready solution. A primary reason for creating a single REST endpoint for retrieving attribution information is that we know this API will be hit hard, and REST endpoints are cacheable. We believe that returning cached responses for all callers will reduce the overall infrastructure impact of introducing this endpoint and recommending attribution signals to key partners and community tools. A properly modularized and unit-tested solution will be easier to maintain and extend in the future.

Conditions of acceptance
  • Refactor handler into a Module/Service
  • Provide config options for props like Logos, icons, sound, etc
  • Make sure the solution has good coverage of both Unit and Integration testing
  • Tests are executed via CI
  • There are no performance concerns ( like ones regarding fetching Contributors count ).
  • Investigate/implement cache support
    • Determine how much caching support works out of the box for MediaWiki cache control
    • Audit returned data to understand how long data should be cached
    • Make a recommendation for implementing a memcache vs longer-lived REST cache
    • Determine if/how the cache can continue being hit, even if the caller is logged in (which normally circumvents the cache for most API requests)
  • Investigate/implement cache purging, particularly for "out of the box" REST caching within MediaWiki
  • Complete OpenAPI Specs that pass linting
  • Bugs and unexpected responses are resolved
Implementation details

The request for continuing to hit the cache even if users are logged in is because attribution data should not change based on user preferences. Ideally, because the data is consistent for all callers, we should not take on the additional burden of returning uncached content.
Additionally, because we are encouraging more users to authenticate, logged-in use cases may become more common, which increases the performance risks.

Risks

There is a way to retrieve contributors count - WikiPage::getContributors(), but it uses a complex SQL query and it may not perform well especally under higher load. We should check if we can use that method, and if not, then we should look into a different way of retreving contributors count.

Notes:

There is an extension that is no longer maintained - Extension:Contributors - which provided a list of most prominent contributors

Event Timeline

pmiazga updated the task description. (Show Details)
pmiazga updated the task description. (Show Details)
Aklapper renamed this task from Productionize the MVP to Productionize the MVP of Attribution API.Tue, Feb 17, 5:24 PM
HCoplin-WMF renamed this task from Productionize the MVP of Attribution API to [5.3.3 Epic] Productionize the MVP of Attribution API.Thu, Feb 19, 2:13 AM
HCoplin-WMF updated the task description. (Show Details)

To make this more iterative, here's my suggestion for MVP/step-one:

  • Refactor business logic out of the Handler and into a dedicated class (no need to make it a just service yet)
  • Add PHP Unit tests to that class
  • Make config variables for the hard-coded urls in there without changing the object structure

Profit.

Then iterate on this and see whether that standalone class should be a service (I instinctively feel that a service may be overkill here, but we can discuss options) or a class that allows some easier internal registry for us to be able to add/adjust fields and manage optional dependencies, etc.

Change #1247619 had a related patch set uploaded (by Atieno; author: Atieno):

[mediawiki/extensions/WikimediaCustomizations@master] Attribution: Refactor the business logic out of the AttributionRestHandler

https://gerrit.wikimedia.org/r/1247619

Change #1248498 had a related patch set uploaded (by Atieno; author: Atieno):

[mediawiki/extensions/WikimediaCustomizations@master] Atribution: Make URLs configurable

https://gerrit.wikimedia.org/r/1248498

Change #1247619 merged by jenkins-bot:

[mediawiki/extensions/WikimediaCustomizations@master] Attribution: Refactor the business logic out of the AttributionRestHandler

https://gerrit.wikimedia.org/r/1247619

Change #1249916 had a related patch set uploaded (by Atieno; author: Atieno):

[mediawiki/extensions/WikimediaCustomizations@master] Atribution: Make brandmark sound URL configurable

https://gerrit.wikimedia.org/r/1249916

Change #1248498 abandoned by Atieno:

[mediawiki/extensions/WikimediaCustomizations@master] Atribution: Make brandmark sound URL configurable

Reason:

new patch https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikimediaCustomizations/+/1249916

https://gerrit.wikimedia.org/r/1248498

Change #1249916 merged by jenkins-bot:

[mediawiki/extensions/WikimediaCustomizations@master] Atribution: Make brandmark sound URL configurable

https://gerrit.wikimedia.org/r/1249916