Before working on this please talk to the Abstract Wikipedia team. This might (later, not now) be a good project for Outreachy, GSoC or similar, and we'd potentially be interested in mentoring/supporting this work, though not before launching Wikifunctions.
Description
The function-evaluator is a critical part of the Wikifunctions stack. It is currently (January 2023) implemented in Node using Wikimedia's service-runner within the service 'template'. Although this is a flexible framework and standard for RESTful services across Wikimedia, it is not very performant and as a critical path through which every Wikifunctions call runs. Improving the speed and reliability of this is important.
Desired behaviour/Acceptance criteria (returned value, expected error, performance expectations, etc.)
The re-write would need…
- … to function as a 'drop-in' replacement for the existing evaluator service, with the current APIs and behaviours;
- … to pass (the equivalent of) all existing unit, integration, and correctness tests;
- … to perform substantially better than the existing service, to make the migration worthwhile;
- … to be in a technology that the team already knows or can reasonably easily learn and use;
- … to be in a technology with a base image supported by SRE, and ideally used by at least one other Wikimedia team, for shared effort around security/maintenance knowledge.
Completion checklist
- Functionality:
- The solution meets the expected behavior/acceptance criteria described above
- All the child tasks are closed
- The issue has been peer reviewed
- The issue has been merged
- Engineering:
- There are existing and passing unit/integration tests effectively testing its success and its failure
- All new classes/methods are covered by unit tests
- Documentation
- All new functions/methods are annotated
- Related documentation in MediaWiki extension pages or Abstract Wikipedia pages in meta should be updated with the related changes
- E.g. New API being created should be reflected in WikiLambda API help page
- E.g. New error types being added should be reflected in the Representation of errors help page
- E.g. New keys being added to built-in types should be reflected in the Function model help page
- Versioning
- If changes in submodule packages are involved, every project that uses this submodule should pass tests and build
- Accessibility:
- New functionality is compared against the Accessibility guide for developers
- Accessibility concerns are either address or, if the work is sufficiently large, a new Phabricator ticket is created and linked to this ticket
- All user facing strings are internationalized