3 ms·

That seems to be using WSGI, not ASGI, though, so no natively `async` views..?

by akx 4y ago

nickjj 4y ago
> That seems to be using WSGI, not ASGI, though, so no natively `async` views..? One does not simply go async. Changing your entire app to go full async has serious implications, requires every library you use to support it and requires a completely different mode of thinking. The example project includes an ASGI file if you want to use an async app server like uvicorn with async views instead of gunicorn. That would involve changing a couple of lines of code. That's very much a "per user" decision and in my opinion shouldn't be the default for the project when 4.1 only landed a few hours ago. It's going to take a long time until apps are ready to go async by default, both from waiting on libraries to support it and the community to shift towards this style of building apps.
- akx 4y ago
  I know one does not simply go async, sure, but I thought it should be noted (especially considering how async-centric this release is) that the repo doesn't immediately allow for async. Also, "4.1 only landed a few hours ago" isn't the perfect argument in my books since support for ASGI and async views in general was added back in 3.0 and 3.1: * https://docs.djangoproject.com/en/4.0/releases/3.0/#asgi-support https://docs.djangoproject.com/en/4.0/releases/3.0/#asgi-sup... * https://docs.djangoproject.com/en/4.0/releases/3.1/#asynchronous-views-and-middleware-support https://docs.djangoproject.com/en/4.0/releases/3.1/#asynchro...
- VWWHFSfQ 4y ago
  > use an async app server like uvicorn with async views instead of gunicorn I believe gunicorn with the uvicorn worker class is the recommended production server. > For production deployments we recommend using gunicorn with the uvicorn worker class. https://www.uvicorn.org/#running-with-gunicorn https://www.uvicorn.org/#running-with-gunicorn
  - nickjj 4y ago
    > I believe gunicorn with the uvicorn worker class is the recommended production server. Yep for production that works. In development tho I don't think the gunicorn --reload flag works with that worker type. There is an issue open for this at https://github.com/benoitc/gunicorn/issues/2339 https://github.com/benoitc/gunicorn/issues/2339 and since I last tried about a year ago I guess they have an unofficial "workaround solution" in one of the comments but it involves making a custom class to support reloading but that requires copying in some code into your project and also using different worker types in dev vs prod. I think this is a good example of why I don't default to uvicorn and async in the project with Django 4.1. The whole package of "async everything" isn't ready for prime time in my opinion. It will improve over time but it's a waiting game at this point. Early adapters can easily swap it in if they want.
    - collinmanderson 4y ago
      Interesting looks like it might actually be a python bug. Somehow just changing from sys.exit(0) -> os._exit(0) apparently fixes it. "There is a problem with using the sys.exit() in a forked process (child processes or workers) instead of using the os._exit() that is mentioned in python documentation." https://github.com/benoitc/gunicorn/pull/2820 https://github.com/benoitc/gunicorn/pull/2820 I've always just needed to manually reload the gunicorn async server in development. Super annoying.
- blitzar 4y ago
  Never go full async

That seems to be using WSGI, not ASGI, though, so no natively `async` views..?

by akx 4y ago

That seems to be using WSGI, not ASGI, though, so no natively `async` views..?

> That seems to be using WSGI, not ASGI, though, so no natively `async` views..? One does not simply go async. Changing your entire app to go full async has serious implications, requires every library you use to support it and requires a completely different mode of thinking. The example project includes an ASGI file if you want to use an async app server like uvicorn with async views instead of gunicorn. That would involve changing a couple of lines of code. That's very much a "per user" decision and in my opinion shouldn't be the default for the project when 4.1 only landed a few hours ago. It's going to take a long time until apps are ready to go async by default, both from waiting on libraries to support it and the community to shift towards this style of building apps.

akx 4y ago
I know one does not simply go async, sure, but I thought it should be noted (especially considering how async-centric this release is) that the repo doesn't immediately allow for async. Also, "4.1 only landed a few hours ago" isn't the perfect argument in my books since support for ASGI and async views in general was added back in 3.0 and 3.1: * https://docs.djangoproject.com/en/4.0/releases/3.0/#asgi-support https://docs.djangoproject.com/en/4.0/releases/3.0/#asgi-sup... * https://docs.djangoproject.com/en/4.0/releases/3.1/#asynchronous-views-and-middleware-support https://docs.djangoproject.com/en/4.0/releases/3.1/#asynchro...
VWWHFSfQ 4y ago
> use an async app server like uvicorn with async views instead of gunicorn I believe gunicorn with the uvicorn worker class is the recommended production server. > For production deployments we recommend using gunicorn with the uvicorn worker class. https://www.uvicorn.org/#running-with-gunicorn https://www.uvicorn.org/#running-with-gunicorn
- nickjj 4y ago
  > I believe gunicorn with the uvicorn worker class is the recommended production server. Yep for production that works. In development tho I don't think the gunicorn --reload flag works with that worker type. There is an issue open for this at https://github.com/benoitc/gunicorn/issues/2339 https://github.com/benoitc/gunicorn/issues/2339 and since I last tried about a year ago I guess they have an unofficial "workaround solution" in one of the comments but it involves making a custom class to support reloading but that requires copying in some code into your project and also using different worker types in dev vs prod. I think this is a good example of why I don't default to uvicorn and async in the project with Django 4.1. The whole package of "async everything" isn't ready for prime time in my opinion. It will improve over time but it's a waiting game at this point. Early adapters can easily swap it in if they want.
  - collinmanderson 4y ago
    Interesting looks like it might actually be a python bug. Somehow just changing from sys.exit(0) -> os._exit(0) apparently fixes it. "There is a problem with using the sys.exit() in a forked process (child processes or workers) instead of using the os._exit() that is mentioned in python documentation." https://github.com/benoitc/gunicorn/pull/2820 https://github.com/benoitc/gunicorn/pull/2820 I've always just needed to manually reload the gunicorn async server in development. Super annoying.
blitzar 4y ago
Never go full async