Repository navigation
Replies: 1 comment
|
Hash-locking is strong provenance: it proves that the reviewed plan is the one that was applied. On its own, though, it should not be treated as a completion signal. A clean source/target diff can still hide changes in authentication, validation details, pagination, status codes, error envelopes, or side effects. The right framing is evidence with an explicit coverage boundary. I would surface that boundary in the normal verify summary:
For the next migration, Flask to FastAPI looks like a useful API-only target. Blueprint routing and common Marshmallow validation patterns provide a recognizable first envelope. I would keep server-rendered templates, implicit globals, and custom middleware chains outside the first supported scope; a narrow boundary makes the verification claim much more meaningful. |
Uh oh!
There was an error while loading. Please reload this page.
Sanka is open source as of this week:
sanka scan / plan / apply / test / verify, first for Django REST Framework to FastAPI (and Flask), with the benchmark at https://sanka.com/bench.We want two things from you:
planis hash-locked andapplyrefuses anything but that hash;verifydiffs the generated app against the source. Is that a convincing "done" signal for a migration? What is missing?Bugs go to issues; the ones labelled
good first issueare real and small. Guide: https://sanka.com/docs/developers/migrate/django-to-fastapi/All reactions