build-a-saas-app-with-flask VS docker-flask-example

I've been maintaining my Build a SAAS App with Flask video course[0] for 8 years. It has gone from pre-1.0 to 2.3 and has been recorded twice with tons of incremental updates added over the years to keep things current.

In my opinion tutorial creators should pin their versions so that anyone taking the course or going through the tutorial will have a working version that matches the video or written material.

I'm all for keeping things up to date and do update things every few months but rolling updates don't tend to work well for tutorials because sometimes a minor version requires a code change or covering new concepts. As a tutorial consumer it's frustrating when the content doesn't match the source code unless it's nothing but a version bump.

I've held off upgrading Flask to 3.0 and Python 3.12 due to these open issues with 3rd party dependencies https://github.com/nickjj/docker-flask-example/issues/17.

[0]: https://buildasaasappwithflask.com/

Build a SAAS App with Flask. Course / Boilerplate. https://buildasaasappwithflask.com/

Personally I maintain https://github.com/nickjj/docker-flask-example. There's also https://github.com/nickjj/build-a-saas-app-with-flask if you want more opinions.

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.... It was using a Flask example repo not Django but everything still applies. The same patterns are used.

Indeed, you can also create a Jinja macro to auto-insert the token into all of your forms too, here's a code example[0]. It's a 100% solved problem both on the Flask back-end and template side with an ability to opt out of it when you need to on the back-end such as accepting webhooks from another service.

[0]: https://github.com/nickjj/build-a-saas-app-with-flask/blob/1...

Gunicorn is one of my favorite app servers. I've been using Gunicorn in production on a bunch of projects (any Flask / Django project) for around 8 years now. It's rock solid and extremely predictable.

I also use Gunicorn in development too, it supports code reloading and also lets you enable Flask's debug middleware so you can use the interactive debugger. This is all configured in my Build a SAAS App with Flask course, a code example is here: https://github.com/nickjj/build-a-saas-app-with-flask.

That makes sense. Also do you have any experience with https://buildasaasappwithflask.com/ ?

Can’t speak to Corey Schafer’s, but I found this course here to be much better than Miguel’s https://buildasaasappwithflask.com/

I've been maintaining my Build a SAAS App with Flask video course[0] for 8 years. It has gone from pre-1.0 to 2.3 and has been recorded twice with tons of incremental updates added over the years to keep things current.

In my opinion tutorial creators should pin their versions so that anyone taking the course or going through the tutorial will have a working version that matches the video or written material.

I'm all for keeping things up to date and do update things every few months but rolling updates don't tend to work well for tutorials because sometimes a minor version requires a code change or covering new concepts. As a tutorial consumer it's frustrating when the content doesn't match the source code unless it's nothing but a version bump.

I've held off upgrading Flask to 3.0 and Python 3.12 due to these open issues with 3rd party dependencies https://github.com/nickjj/docker-flask-example/issues/17.

[0]: https://buildasaasappwithflask.com/

I usually end up with project specific "run" scripts which are just shell scripts so I can do things like `./run shell` to drop into the shell of a container, or `./run rails db:migrate` to run a command in a container.

Here's a few project specific examples. They all have similar run scripts:

    - https://github.com/nickjj/docker-flask-example

There's a lot of "tool" selections in that repo.

If anyone is looking for ready to go web app examples aimed at both development and production, I maintain:

    - https://github.com/nickjj/docker-flask-example

Personally I maintain https://github.com/nickjj/docker-flask-example. There's also https://github.com/nickjj/build-a-saas-app-with-flask if you want more opinions.

This is what I do except I use a shell script instead of a Makefile.

A working example of this is at: https://github.com/nickjj/docker-flask-example/blob/912388f3...

Those ./run ci:XXX commands are in: https://github.com/nickjj/docker-flask-example/blob/912388f3...

I like it because if CI ever happens to be down I can still run that shell script locally.

> I've encountered a code written in the 12factor style of using environment variables for configuration, and in that particular case there was no validation nor documentation of the configuration options. Is this typical?

I don't know about typical, it comes down to how your team values the code they write.

You can have a .env.example file commit to version control which explains every option in as much or as little detail as you'd like. For my own personal projects, I tend to document this file like this https://github.com/nickjj/docker-flask-example/blob/main/.en....

I did this for a while but make isn't well suited for this use case. What I end up doing is have a shell script with a bunch of functions in it. Functions automatically becomes a callable a command (with a way to make private functions if you want) with pretty much no boiler plate.

The benefit of this is it's just shell scripting so you can use shell features like $@ to pass args to another command or easily source and deal with env vars.

I've written about this process at https://nickjanetakis.com/blog/replacing-make-with-a-shell-s... and an example file is here https://github.com/nickjj/docker-flask-example/blob/main/run.

There's: https://github.com/nickjj/docker-flask-example