Change Details

==Background/Goal The [[ https://wikitech.wikimedia.org/wiki/AQS_2.0 | AQS 2.0 ]] project initially used the [[ https://github.com/julienschmidt/httprouter | httprouter package ]]. While it initially met our needs, we encountered a [[ https://github.com/julienschmidt/httprouter/issues/208 | long-standing encoding issue ]]. This issue not only [[ https://phabricator.wikimedia.org/T299735#8347852 | blocked our unit tests ]], but more importantly would not have properly handled production url parameters (such as page titles with encodings). We fairly quickly evaluated [[ https://github.com/gorilla/mux | gorilla/mux ]] and [[ https://github.com/valyala/fasthttp | fasthttp ]], and [[ https://phabricator.wikimedia.org/T299735#8410267 | chose fasthttp ]]. This fixed the encoding issues, unblocked the unit tests, and allowed us to move forward. However, we are now considering [[ https://phabricator.wikimedia.org/T325524 | pushing the router change upstream to the Go service scaffolding ]], and it is a good time to evaluate how satisfied we are with fasthttp. Pushing to scaffolding means other projects are likely to use this router as well, leading to more widespread refactoring if we determine in the future that it was not our best option. So this decision is impactful, and deserves additional thought before we proceed. The goal of this task is to have confidence that we are happy with whatever router we choose to use going forward. While completion of this task may involve exploratory coding, this is primarily a decision-making task, not a coding one. If our evaluation results in a choice other than fasthttp, we can make coding changes to the AQS 2.0 codebase and Go service scaffolding under as many separate tasks as are needed. ==Acceptance Criteria This task is complete when the involved parties are in agreement on the choice of router. == Key Tasks [] Criteria for evaluating routers is established [] Candidate routers are identified [] Candidate routers are evaluated [] A choice of router package is made [] Any necessary followup tasks are created I'm assigning this task to myself for tracking purposes, but this is a collaborative effort, not a unilateral one. Thoughts and feedback are welcome and encouraged. I'm also titling this as an AQS 2.0 task, as that is the active project that is affected. However, as discussed, this task has wider implications.

==Background/Goal The [[ https://wikitech.wikimedia.org/wiki/AQS_2.0 | AQS 2.0 ]] project initially used the [[ https://github.com/julienschmidt/httprouter | httprouter package ]]. While it initially met our needs, we encountered a [[ https://github.com/julienschmidt/httprouter/issues/208 | long-standing encoding issue ]]. This issue not only [[ https://phabricator.wikimedia.org/T299735#8347852 | blocked our unit tests ]], but more importantly would not have properly handled production url parameters (such as page titles with encodings). We fairly quickly evaluated [[ https://github.com/gorilla/mux | gorilla/mux ]] and [[ https://github.com/valyala/fasthttp | fasthttp ]], and [[ https://phabricator.wikimedia.org/T299735#8410267 | chose fasthttp ]]. This fixed the encoding issues, unblocked the unit tests, and allowed us to move forward. However, we are now considering [[ https://phabricator.wikimedia.org/T325524 | pushing the router change upstream to the Go service scaffolding ]], and it is a good time to evaluate how satisfied we are with fasthttp. Pushing to scaffolding means other projects are likely to use this router as well, leading to more widespread refactoring if we determine in the future that it was not our best option. So this decision is impactful, and deserves additional thought before we proceed. The goal of this task is to have confidence that we are happy with whatever router we choose to use going forward. While completion of this task may involve exploratory coding, this is primarily a decision-making task, not a coding one. If our evaluation results in a choice other than fasthttp, we can make coding changes to the AQS 2.0 codebase and Go service scaffolding under as many separate tasks as are needed. ==Acceptance Criteria This task is complete when the involved parties are in agreement on the choice of router. == Key Tasks [x] Criteria for evaluating routers is established [x] Candidate routers are identified [x] Candidate routers are evaluated [x] A choice of router package is made [x] Any necessary followup tasks are created I'm assigning this task to myself for tracking purposes, but this is a collaborative effort, not a unilateral one. Thoughts and feedback are welcome and encouraged. I'm also titling this as an AQS 2.0 task, as that is the active project that is affected. However, as discussed, this task has wider implications.

==Background/Goal The [[ https://wikitech.wikimedia.org/wiki/AQS_2.0 | AQS 2.0 ]] project initially used the [[ https://github.com/julienschmidt/httprouter | httprouter package ]]. While it initially met our needs, we encountered a [[ https://github.com/julienschmidt/httprouter/issues/208 | long-standing encoding issue ]]. This issue not only [[ https://phabricator.wikimedia.org/T299735#8347852 | blocked our unit tests ]], but more importantly would not have properly handled production url parameters (such as page titles with encodings). We fairly quickly evaluated [[ https://github.com/gorilla/mux | gorilla/mux ]] and [[ https://github.com/valyala/fasthttp | fasthttp ]], and [[ https://phabricator.wikimedia.org/T299735#8410267 | chose fasthttp ]]. This fixed the encoding issues, unblocked the unit tests, and allowed us to move forward. However, we are now considering [[ https://phabricator.wikimedia.org/T325524 | pushing the router change upstream to the Go service scaffolding ]], and it is a good time to evaluate how satisfied we are with fasthttp. Pushing to scaffolding means other projects are likely to use this router as well, leading to more widespread refactoring if we determine in the future that it was not our best option. So this decision is impactful, and deserves additional thought before we proceed. The goal of this task is to have confidence that we are happy with whatever router we choose to use going forward. While completion of this task may involve exploratory coding, this is primarily a decision-making task, not a coding one. If our evaluation results in a choice other than fasthttp, we can make coding changes to the AQS 2.0 codebase and Go service scaffolding under as many separate tasks as are needed. ==Acceptance Criteria This task is complete when the involved parties are in agreement on the choice of router. == Key Tasks [x] Criteria for evaluating routers is established [x] Candidate routers are identified [x] Candidate routers are evaluated [x] A choice of router package is made [x] Any necessary followup tasks are created I'm assigning this task to myself for tracking purposes, but this is a collaborative effort, not a unilateral one. Thoughts and feedback are welcome and encouraged. I'm also titling this as an AQS 2.0 task, as that is the active project that is affected. However, as discussed, this task has wider implications.