Page MenuHomePhabricator

Explore re-writing the function-evaluator into a more performant, strongly-typed language (TypeScript/rust/golang/etc.)
Open, MediumPublic

Description

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