I have doubts about the design and on spot decision of using FastAPI.
It’s kind of chicken and the egg problem. If author knows FastAPI then it’s great, but if not then should verify its applicability. It might not be the choice they’d make and need to verify both library and other solution if it’s not the fit.
If I’d get suggestion like that I’d immediately go to documentation because I don’t know consequences. Experienced person might make a conscious choice, unexperienced - implicit one which might not work in context.
As for the design - I’m against inlining handlers. It’s not like Python is the only language that allows it, but I would suspect consequences are very similar. But maybe that’s idiomatic thing. Had this be coming from documentation I’d had much more faith than a random LLM suggestion.
FastAPI is a nobrainer choice of webserver backend for a python API server in 2024. If you’re not aware of that, then you really shouldn’t be commenting on this topic.
It’s kind of chicken and the egg problem. If author knows FastAPI then it’s great, but if not then should verify its applicability. It might not be the choice they’d make and need to verify both library and other solution if it’s not the fit.
If I’d get suggestion like that I’d immediately go to documentation because I don’t know consequences. Experienced person might make a conscious choice, unexperienced - implicit one which might not work in context.
As for the design - I’m against inlining handlers. It’s not like Python is the only language that allows it, but I would suspect consequences are very similar. But maybe that’s idiomatic thing. Had this be coming from documentation I’d had much more faith than a random LLM suggestion.