5 ms·

If anyone is interested I updated my example Django Docker app to 4.1 at: https://github.com/nickjj/docker-django-example https://github.com/nickjj/docker-djang

by nickjj 4y ago

If anyone is interested I updated my example Django Docker app to 4.1 at: https://github.com/nickjj/docker-django-example https://github.com/nickjj/docker-django-example It includes running Django, Celery, gunicorn, Postgres, Redis, esbuild and Tailwind through Docker and Docker Compose. It's set up for development and production.

fredsmith219 4y ago
This is very cool. Thank you.
akx 4y ago
That seems to be using WSGI, not ASGI, though, so no natively `async` views..?
- 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
omarhaneef 4y ago
I was going to say you should offer a tutorial around how this can be used. It is much more useful to have a walk through when people put out such products. And then I decided not to say that because it is up to you how to spend your time and why should you make a tutorial for people if you don't want to. And then I realized, you have actually made dozens and this is the work you do. I think I took a Flask-docker course of yours on Udemy a few years ago. It was pretty good, and "forward leaning" for the time. I know you're not allowed to shill your product on here, but presumably I can.
- nickjj 4y ago
  Thanks a lot! By the way the version of the course on Udemy doesn't get updated. The full version of the course is at https://buildasaasappwithflask.com/ https://buildasaasappwithflask.com/ which includes lifetime free updates (it has over 10+ hours of extra updates and new features not on the Udemy version). Udemy is a really bad platform for instructors which is why I've been trying hard to decouple myself from them over time. As for a tutorial on using this repo specifically, did you find the readme file lacking in any way? I tried to write the readme to be fully self contained. It would expect prior Docker knowledge tho. I did give a talk at DockerCon going over a bunch of Docker best practices at https://nickjanetakis.com/blog/best-practices-around-production-ready-web-apps-with-docker-compose https://nickjanetakis.com/blog/best-practices-around-product.... That talk live demos a Flask example app not Django but everything still applies to Django. The same patterns are used in both projects. It can act as a mini-tutorial on this repo.
  - soperj 4y ago
    I was going to say that you should really camelcase your url, because it's hard to see what it's saying, but even when you do that... https://buildASASSAppWithFlask.com/ https://buildASASSAppWithFlask.com/ doesn't really help that much hahaha.
    - impjohn 4y ago
      https://buildwithflask.com/ https://buildwithflask.com/ is the better name
kolanos 4y ago
> CMD ["gunicorn", "-c", "python:config.gunicorn", "config.wsgi"] Looks like this example is still WSGI?
- nickjj 4y ago
  Yep but it includes "config.asgi" which you can use with gunicorn's uvicorn worker or uvicorn if you want if you want to use async views.
ydnaclementine 4y ago
Thanks for this. I've been learning django and have been struggling to find a good example of a way to integrate modern js into django. Unfortunately not as much support as rails + esbuild

by nickjj 4y ago

fredsmith219 4y ago

This is very cool. Thank you.

akx 4y ago

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

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

omarhaneef 4y ago

I was going to say you should offer a tutorial around how this can be used. It is much more useful to have a walk through when people put out such products. And then I decided not to say that because it is up to you how to spend your time and why should you make a tutorial for people if you don't want to. And then I realized, you have actually made dozens and this is the work you do. I think I took a Flask-docker course of yours on Udemy a few years ago. It was pretty good, and "forward leaning" for the time. I know you're not allowed to shill your product on here, but presumably I can.

nickjj 4y ago
Thanks a lot! By the way the version of the course on Udemy doesn't get updated. The full version of the course is at https://buildasaasappwithflask.com/ https://buildasaasappwithflask.com/ which includes lifetime free updates (it has over 10+ hours of extra updates and new features not on the Udemy version). Udemy is a really bad platform for instructors which is why I've been trying hard to decouple myself from them over time. As for a tutorial on using this repo specifically, did you find the readme file lacking in any way? I tried to write the readme to be fully self contained. It would expect prior Docker knowledge tho. I did give a talk at DockerCon going over a bunch of Docker best practices at https://nickjanetakis.com/blog/best-practices-around-production-ready-web-apps-with-docker-compose https://nickjanetakis.com/blog/best-practices-around-product.... That talk live demos a Flask example app not Django but everything still applies to Django. The same patterns are used in both projects. It can act as a mini-tutorial on this repo.
- soperj 4y ago
  I was going to say that you should really camelcase your url, because it's hard to see what it's saying, but even when you do that... https://buildASASSAppWithFlask.com/ https://buildASASSAppWithFlask.com/ doesn't really help that much hahaha.
  - impjohn 4y ago
    https://buildwithflask.com/ https://buildwithflask.com/ is the better name

kolanos 4y ago

> CMD ["gunicorn", "-c", "python:config.gunicorn", "config.wsgi"] Looks like this example is still WSGI?

nickjj 4y ago
Yep but it includes "config.asgi" which you can use with gunicorn's uvicorn worker or uvicorn if you want if you want to use async views.

ydnaclementine 4y ago

Thanks for this. I've been learning django and have been struggling to find a good example of a way to integrate modern js into django. Unfortunately not as much support as rails + esbuild