Hacker News Reader

Comment by nickjj | Hacker News Reader

If anyone is interested I updated my example Django Docker app to 4.1 at: 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.

View on HN

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.

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/ 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-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.

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/ doesn't really help that much hahaha.

https://buildwithflask.com/ is the better name

I have not tried it, but I believe I could download it and set up the app based on the readme.

I would not be confident using it, but I'll give it a try.

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

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.

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-sup... * https://docs.djangoproject.com/en/4.0/releases/3.1/#asynchro...

> 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

> 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 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.

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

I've always just needed to manually reload the gunicorn async server in development. Super annoying.

Never go full async

> CMD ["gunicorn", "-c", "python:config.gunicorn", "config.wsgi"]

Looks like this example is still WSGI?

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.

This is very cool. Thank you.

Reply on news.ycombinator.com