fastapi-crudrouter VS aiomultiprocess

FastAPI does have an equivalent. Something like this? https://github.com/awtkns/fastapi-crudrouter

I can't show any pics cuz of uk NDA and all that. I can tell you the gist of it though. FastAPI is already pretty good at the abstraction part. Our middleware had a lot of rerouting and it was basically just a bunch of redundant functions. I just used this cool ass package https://fastapi-crudrouter.awtkns.com/ and used the partial function from functools to generate endpoints for every scenario/db tables.

Thanks, that's a really helpful example.

Where I think this could be taken to the next level of reusability is in modularising the front-end into API-specific components. For example, the login behaviour could depend on FastAPI-Users, with a sibling frontend library containing components that implement the same login flow. Adding user behaviour is then a matter of using the same third-party library on the front and back end.

This approach could be extended to other components such as an admin panel (perhaps using https://github.com/awtkns/fastapi-crudrouter), or a blogging component.

> Why not just use multi processing?

Multiprocessing provides parallelism up to what the machine supports, but no additional degree of concurrency, asyncio provides a fairly high degree of concurrency, but no parallelism.

OF course, you can use them together to get both.

https://github.com/omnilib/aiomultiprocess

Take a look at aiomultiprocess. It combines multiprocessing and asynchio to bypass the GIL for greatly increased performance.