Enhancement: When there is a process running, the starlette-admin is not responsive until the process is completed

[magedhelmy1]

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is.

• Execute a 10+ second job
• click around in the admin page, and it will not be responsive until the job is complete

Describe the solution you'd like
A clear and concise description of what you want to happen.

• The admin panel is responsive when their are processes running
• In production, where they are thousands of requests coming, it will be good that the admin panel is still usable like in Django.

models.Base.metadata.create_all(bind=engine)

app = FastAPI()

admin = Admin(engine, title="V2")

# Mount admin to your app
admin.mount_to(app)

# For demonstration: logging when the routers are added
logger.info("Routers and admin views added to the app")

[hasansezertasan]

Can you share a MRE? The code block you've sent doesn't have much configuration.

[sglebs]

This is intrinsic in async programming in single threaded VMs like CPython. NodeJS would have the same problem. You are blocking the Python VM, which does not have a very good multithreading implementation. You can use $WEB_CONCURRENCY to get N uvicorns running in the same process. Or you can use gunicorn with multiple workers. Or you can use celery to run your slow job asynchronously in another Python VM. But basically the problem you are having is not starlette-admin's fault at all.

For example, for gunicorn you can set these env vars:

FORWARDED_ALLOW_IPS="*"
GUNICORN_CMD_ARGS="-w 1 -k uvicorn.workers.UvicornWorker --bind=0.0.0.0:8888 --proxy-protocol --proxy-allow-from *"

And use this cmd-line to launch your app:

gunicorn webapp.main:app

I am assuming above that you have a file webapp.py and that it has the app as an "app" instance (module variable). Adapt it to your needs.

On the other hand, you can keep using uvicorn (not recommended for production in their documentation) and just set this env var:

WEB_CONCURRENCY=3

You will get 3 async io loops, so you can block 1 VM for 10 seconds and you will still have 2 to handle requests. But if all your VMs have to handle the slow task, then you are back to where you started. Use Celery then.

But the rule of thumb is: do NOT use non-async blocking operations(say a synchronous slow database query) or long running CPU-bound code in a responsive async-based server.