Skip to content


The problem with _micro_ frameworks is a lack of structure #658

daGrevis opened this Issue · 12 comments

8 participants


So here is my pain — there are no structure restrictions. Single file is fine until there are more than X lines. And apps do grow. Very fast. No restrictions are good, but structure skeletons are awesome. Let me explain it...

I had big problems w/ re-structuring my app so that everything is not in a single file. I'm just a newbie programmer, not an architect. At least for now. Micro frameworks should improve my productivity, not forcing me to structure things.

I suggest to create skeletons / boilerplate for possible ways to structure app. They could be sorted for estimated size of the product (tiny, small, medium, big & huge) plus used components (ORM, template engine, test framework, form abstraction etc.). What do you think?


I'm sorry but I don't agree at all if the idea behind this ticket is to add those features to Flask itself. I see the lack of a pre-defined structure as a feature, not a problem, and it's one of the reasons I don't use tools like Django or Ruby on Rails anymore.

The reality is, while an opinionated project structure would certainly make some new programmers a bit more comfortable, those of us who use Flask daily and are quite comfortable with how it works would find that opinionated structure to be mental overhead; another thing to have to ignore, or configure away when I don't want it.

One of my favorite things about Flask is the ability to start small, and then grow the project's complexity as the actual project is built. It's very very rare that a project's final size can be estimated at the beginning as you stated and so you'd simply end up back where you are now if you selected a skeleton that was too "small" or you'd be in dependency overhead hell if you selected a skeleton that was too "large."

Lastly, Flask's documentation is excellent when it comes to directing you on how you might want to structure a larger application: and beyond that there are hundreds of Flask based applications on github and bitbucket that you could look at to get an idea of how to structure your larger application.

Now I do support the idea of a 3rd party project that could provide this feature. There are already a few out there like flask-boilerplate and fbone.

If you absolutely have to be told what structure and extensions to use in order to be productive, you probably don't want a micro framework at all. You want a complete, kitchen-sink type of framework, and that's fine. For that case there is Django, Pyramid, and TurboGears.


You seem to have a contradiction — on the one hand you want a structure provided for Flask apps, but on the other hand, you seem to balk at the examples showing everything in the same source. It seems to me that you actually have a problem with the way apps are typically structured using flask, not that they lack structure.

That said, I completely disagree with you. One of the appeals of Flask is that it is really easy to get started with and it lacks the learning curves associated with Django, Pyramid, TurboGears, RoR, etc.

Additionally, you'd probably find that trading the flexibility of Flask for the imposed structures of Django or RoR carries some drawbacks in addition to the perceived benefits. With tools like Django, you have to craft your solution to fit the model imposed by the framework. With Flask, because it doesn't impose a heavy structure on you, you have the flexibility to model your solution in the way that makes the most sense to you. It's a tradeoff that's worth considering.

As far as boilerplate, the flask project itself includes a few example apps and the documentation is excellent.


@apiguy Thanks for those links, it's enough and I don't think that it must be added to source code of Flask itself.
@mizhi Thanks for your response!

P.S. I didn't close issue because I want to hear @mitsuhiko feedback too!


Just an observation... Although I have spent years with django and much less time with Flask, I DO find it productive to learn from real-world-grade implementations based on Flask. Typical apps involve common patterns. Although the docs are excellent, many learn first by reviewing best-case examples ALONG with good docs. I have personally made several REDO's of one of my apps with a view toward finding the RIGHT/BEST PRACTICE approach to achieve the objective. Again, although I see the value and have selected Flask (after getting cozy with a number of other python frameworks) based on its focus of NOT imposing structure, I am grateful for the mention just in THIS thread regarding fbone and flask-boilerplate. I would like to add a couple I also am currently learning much from: flask-kit, hip-flask, flask-security.

What occurs to me would be perhaps a structure based on django's approach. Folks coming from django would be able to very quickly proceed from that. I always appreciate when the docs compare what django/others do with what is/can be done in flask... perhaps by using certain extensions.

Thanks again for everyone involved in making flask available.


@LarryEitel I definitely see a value in comparing/contrasting between different frameworks. I've not used Django all that much, but if you're coming from that model, it could help to see how to do it in Flask. Perhaps it may be a worthwhile endeavor to add to some of the examples currently in the repository?


@mizhi I recognize everyone is busy. Likely if/when this idea is pursued, someone that is both conversant in djangop/flask would be best qualified for this.


It is easy to split up a flask project and it is even described in the docs how to do so. I don't see the problem here. Maybe it should be more prominently displayed, sure, but it is there. If it weren't, my sigmavirus24/mock_github_api project would be one horribly large file (eventually).

Edit and I can not find where in the docs I saw how to properly structure multi-file applications. In short, I have the following working:

application_dir/  # where app is defined and a few others  # defines one set of related views  # defines another set
  # etc.

And looks like:


# Other information, author, version, copyright

import application_dir.file1
import application_dir.file2
# etc

I had some problems w/ importing app in tests in such way so that database is not actually created and so I can create temporary test database.


@sigmavirus24 I think this may be what you were looking for -


@chauncey seems to be what I remember reading. I could be wrong though, it was a while ago.


My reply to that is that we should have better docs that outline how to structure apps. I don't want Flask to force structure.

@mitsuhiko mitsuhiko closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.