Change Details

**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 [[https://gitlab.wikimedia.org/repos/abstract-wiki/wikifunctions/function-evaluator|function-evaluator]] is a critical part of the Wikifunctions stack. It is currently (January 2023) implemented in Node using Wikimedia's [[https://github.com/wikimedia/service-runner|service-runner]] within the [[https://github.com/wikimedia/service-template-node|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

**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 Some parts of the function evaluator have already been ported to Rust. This quarter, we can combine these parts into a Rust-based service to replicate the functionality of the current Node-based one. **Desired behaviour/Acceptance criteria (returned value, expected error, performance expectations, //etc.//)** [ ] new service can accept all current versions of the evaluator request format [ ] new service can run function calls in the executor for the appropriate programming language [ ] new service runs function calls in separate threads [ ] new service maintains a pool of "hot" executor interfaces in order to avoid incurring WASI startup costs at request time [ ] new service returns all (appropriate/feasible) metadata supported by the current Node-based evaluator [ ] new service implements a time limit [ ] new service implements a rate limit ---- ## Motivation and Context The [[https://gitlab.wikimedia.org/repos/abstract-wiki/wikifunctions/function-evaluator|function-evaluator]] is a critical part of the Wikifunctions stack. It is currently (January 2023) implemented in Node using Wikimedia's [[https://github.com/wikimedia/service-runner|service-runner]] within the [[https://github.com/wikimedia/service-template-node|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.

**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 [[https://gitlab.wikimedia.org/repos/abstract-wiki/wikifunctions/function-evaluator|function-evaluator]] is a critical part of the Wikifunctions stack. It is currently (January 2023) implemented in Node using Wikimedia's [[https://github.com/wikimedia/service-runner|service-runner]] within the [[https://github.com/wikimedia/service-template-node|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.Some parts of the function evaluator have already been ported to Rust. This quarter, Improving the speed and reliabiwe can combine these parts into a Rust-based service to replicate the functionality of this is important. e current Node-based one. **Desired behaviour/Acceptance criteria (returned value, expected error, performance expectations, //etc.//)** The re-write would need…[ ] new service can accept all current versions of the evaluator request format [ ] … to function as a 'drop-in' replacement fornew service can run function calls in the existing evaluaecutor service, with the current APIs and behaviours;for the appropriate programming language [ ] … to pass (the equivalent of) all existing unit, integration, and correctness tests;new service runs function calls in separate threads [ ] … to perform substantially better than the existing service, to make the migration worthwhile; [ ] new service maintains a pool of "hot" executor interfaces in order to avoid incurring WASI startup costs at request time [ ] new service returns all (appropriate/feasible) metadata supported by the current Node-based evaluator [ ] … to be in a technology that the team already knows or can reasonably easily learn and use;new service implements a time limit [ ] … 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.new service implements a rate limit ---- ## Comple## Motivation checklistand Context [ ] 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: The [[https://gitlab.wikimedia.org/repos/abstract-wiki/wikifunctions/function-evaluator|function-evaluator]] is a critical part of the Wikifunctions stack. [ ] New functionality is compared against the Accessibility guide for developers [ ] Accessibility concerns are either address or,It is currently (January 2023) implemented in Node using Wikimedia's [[https://github.com/wikimedia/service-runner|service-runner]] within the [[https://github.com/wikimedia/service-template-node|service 'template']]. if the Although this is a flexible framework is sufficiently largeand standard for RESTful services across Wikimedia, a new Phabricator ticket is created and linked to this ticket it is not very performant and as a critical path through which every Wikifunctions call runs. [ ] All user facing strings are internationalized Improving the speed and reliability of this is important.