Tech Debt: Refactor report version access middleware
- Lingua principale
- Nessun dato sulla lingua
- Stelle
- 0
- Fork
- 0
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Descrizione
#### Description of the Tech Debt
We have a `withRuleHasRegisteredOperation` middleware that queries the API on every request, whether a user has access to the reporting module (if it has a registered operation) and that tries to extract a report version to check against.
This is basically an extra request to ask the API "is the request I'm about to make legit, and how is it going to fail?"
We could instead refactor how the server responds, if we could use either HTTP codes, a { redirect: ... } key in the ninja schema, or a combination of things between the python API and the `actionHandler()` method
There is a bit of exploration needed here, to see what would be the most effective and if there are NextJS best pratices
#### Tech Debt Triage
The purpose of our technical debt triage process is to analyze technical debt to determine risk level of the technical debt and the value in tackling that technical debt.
#### Risk Value Scoring:
| Level | Value |
| ------ | --------------------- |
| High |
| Medium |
| Low |
| Technical Debt - Risk Types | Level | Value |
| ----------------------------------------------------------------------------------------------------------------------------- | ----- | ----- |
| Business Area Risk - Risk of business area visibility / damage to user experience | 0 | 0 |
| Developer Fault Risk - How likely will this tech debt cause a future error related to coding on top of it | 0 | 0 |
| System Fault Risk - Risk of system errors or application downtime | 0 | 0 |
| Time Scale Risk - Compound risk effect if left alone. How much more difficult to fix or dangerous will this become over time? | 0 | 0 |
| Time Sink Risk - How much will this tech debt slow the development process down | 0 | 0 |
|
#### Development Checklist:
- [ ] Checklist item
- [ ] Checklist item
- [ ] Checklist item
Guida per i contributori
Nessuna guida per i contributori indicizzata per questo repository
Direzione di ricerca
Inizia tracciando il middleware withRuleHasRegisteredOperation e il punto di ingresso actionHandler(), quindi esamina come la Python API segnala attualmente gli errori di accesso e di report-version. Confronta le possibili risposte HTTP-code o di reindirizzamento con le pratiche rilevanti di NextJS. Il lavoro è completo quando il team ha selezionato e documentato un approccio alla risposta che eviti la richiesta API aggiuntiva preservando al contempo il comportamento di errore richiesto.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Valutazione
- Stack tecnologico
- nextjs, python
- Ambito
- api, backend-api-design
- Tipo di issue
- Refactoring
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Stato di attività
- Ferma
- Chiarezza
- Da chiarire
- Idoneità per principianti
- 25/100