Compare Two Prüfidentifikatoren of Different Formatversions

[hf-krechan]

A frequently asked feature is the comparison between two prüfis.

We should start with a MVP to start with this feature.

[hf-kklein]

@OLILHR s ahlbatross does exactly this :) And it has proper tests, a well thought out data model and all that already in place. What ahlbatross still lacks is the use of the xml-based data model as a basis Hochfrequenz/ahlbatross#133 as it was originally written based on the now depreated kohlrahbi/maus models.

Maybe you can encapsulate the business logic from ahlbatross into a little API (be it Azure Function or a simple (FastAPI+Docker) app - as of today I'd probably use the latter), just like we did with e.g. inahbicht+ahbicht-functions, fristenkalender_generator+fristenkalender functions etc.

I think in order to keep things maintainable and reusable, it's important to have a clear separation of responsibilities and split the bare data comparison logic (ahlbatross) from the "display data" part (which is ahb-tabellen in my understanding).

[hf-krechan]

it comes really close and we can build on top of it.

I asked Leon to continue with ahlbatross and check if we can switch from the csv to the sqlite database.

Another usecase I got from the users of AHB-Tabellen is the comparison between two Prüfis of the same Formatversion, e.g. 55001 and 55002 just to see the where they differ.

be it Azure Function or a simple (FastAPI+Docker) app - as of today I'd probably use the latter

Why do you prefer FastAPI instead of Azure Functions?

[hf-kklein]

to the sqlite database

just to emphasize: to me it's not important whether we use the sqlite or bare XML as long as whatever we use is properly typed 🤓 an in that sense a bunch of untyped/stringly typed CSV rows is not better than a bunch of untyped/stringly typed rows from a database. That's why in ahlbatross also the diff-result is well typed. If you use python and the fundamend[sqlmodel] package the sqlite-rows are already well-typed and you can build upon that.

[hf-kklein]

Why do you prefer FastAPI instead of Azure Functions?

I think it sums up as YAGNI.

• no vendor lockin to Azure
• no headache with the restrictions of azure functions
  • no headache with supported python versions (see e.g. https://github.com/hochfrequenz/ahbicht-functions?tab=readme-ov-file#troubleshooting )
  • no headache with missing binaries for obscure dependencies
• better testing support in FastAPI than in Azure Functions (or we've just been doing it wrong the last years)
• OpenApi specs + swagger UI out of the box instead of not
• app starts up and shuts down when we tell it to, not when it feels like ;)

I think we had only half the problems with ahbicht-functions if we had just built a proper FastAPI, but at the time - was FastAPI even around? and we had running Azure Functions (c#) already in place. Also we lacked the containerization capacities&skills back then. now that we have tons of copy paste-templates for "FastAPI app in a docker container", why shouldn't we go with this approach and even think of using Azure Functions?