Enjoyed reading through the approach you take and I'll spend some time reading through the code tomorrow to see how it all fits together. It's surprisingly infrequent that an article pops up describing the thought process behind using a specific structure for your code - thanks for taking the time to write it up.

One thing I've done differently on my last couple of projects is to put the core parts of the app into their own packages at the top level and to make a 'web' package that just contains the web interface and the config. That way I make sure that the core application code isn't bound to the web framework at all. Then within my web blueprints they import the bits of the core library they need to do their work. I can then use the main bit of the library myself without having anything to do with the flask app.

The web app itself is responsible for creating a db connection and then injecting that into the core when needed. I've made a simple gateway class that wraps the db connection and deals with persistence.

The data layer is the bit I'm least happy with. Mostly that's because I went with a nosql solution for the db which ultimately has made the data model more complex than it needs to be. Tomorrow I'm going to experiment with switching to SQLAlchemy again to see how that effects things.

Definitely not saying it's the right way to do things but it's another take on how you can structure things and it's been working really well for me. Feels like you're writing an application first and a website second - which changes how you think about the code.

I hear you on the "core" library idea. I have strived for this separation before with varying success. I just did not feel as if I wanted to go that far with this article.

Thanks for sharing this, it's always nice to hear how other people are set up. Out of curiosity, how do you serve your static files?

With Nginx as a reverse proxy whenever possible.

Have there been any recent rumblings on #pocoo on extension approval?

It'd be great to see Flask-Security gain more prominence (after you change the default away from plaintext of course :)

It's only plaintext by default to get up and running as fast as possible, which is why I wrote the extension in the first place. Armin has, on occasion, expressed interest in improving the extension ecosystem but nothing specific yet.

I didn't even manage to change it. Tried all three values for SECURITY_PASSWORD_HASH mentioned in the docs and nothing worked (i.e. still plain text).

This was just a test project of mine so I used the settings like this (in my app.py file):

    SECURITY_PASSWORD_HASH = 'pbkdf2_sha512'
    app = Flask(__name__)
    app.config.from_object(__name__)

If you set the password hash type to something other than plaintext you also need to set the `SECURITY_PASSWORD_SALT` configuration option.