Part 2 :)

> I feel like your reasoning to avoid fast api didn't make a ton of sense to me. In pydantic you can be as constraining or not as you wish, but it's super nice to define these schemas upfront.

I know how nice Pydantic and FastAPI is. I have some APIs written in it and love it. As noted, I also use Pydantic extensively since it's also the class basis for our data access layer via Beanie.

But let me give you an example of why the juice isn't worth the squeeze here.

I have a web form like this:

Name: ________
Email: ________
Age: ________

I can model it with Pydantic as:

class CreatePerson(BaseModel):
name: str
email: str
age: int

But this will not do for a web form. If the user forgets to fill out one field, I want to say "oops, please fill out age", not HTTP 400 bad request.

Ok, then we can make age: int optional via age: int|None. Cool.

What if they swap email and age and write a string there. Well, still don't want HTTP 400 bad request. So now age has to be age: int|str|None and of course name and email have to be optional again.

Now they can submit the form! In my code though I still have to parse the darn age:

try:
model.age = int(model.age)
except ValueError:
return "form with error message that age isn't valid as a number"

And on and on it goes. So yes, we can make Pydantic bend over to adapt. But at this point, just handle it differently. It's cleaner and simpler. That's what I'm talking about in the challenges of using FastAPI for primarily server side HTML sites.

Hey! Let me respond in two subthreads here since the two topics you bring up are pretty unrelated (but both interesting):

> I really wish I could do this for our APIs except we're talking tens if not hundreds of thousands of lines that would need to be looked at to support a transition from sync to async code.

I think there are tools and techniques you can apply. Here are 3 ideas:

1. mypy supports checking for mistakes around using async functions. See https://mypy.readthedocs.io/en/stable/error_code_list2.html#check-that-awaitable-return-value-is-used-unused-awaitable You could employ tools like mypy (and ideally Ruff in the future) to cache what would have otherwise been missed. This would make the "looking over" part less risky.

2. Switch to a framework like quart or fastapi that supports both sync and async code. Take sections that would benefit a lot from async and rewrite them in async and leave the rest along. This would mean a little duplication. For example if you data layer has a def get_report(), you'd also need an async def get_report_async() or whatever you call it's async twin. This is a hassle but also a way to build in lower level async support that is tested and you can later delete the sync version if you go full async.

3. Use some code that adapts from sync -> async -> sync. I had this for our site running for a few years (!) because I wanted to use Beanie which is only async but the framework, Pyramid, was only sync and I needed to bridge the gap. Was excellent actually for what you could expect of it.