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