Comment by gedrap | Hacker News Reader

Comment by gedrap | Hacker News Reader

One tip if you are about to write your first large (well, larger than 500 lines of code) Flask application: check some example applications for ideas of separation/architecture and some popular modules.

The minimalist nature of Flask, not forcing you to do things in one way and one way only, gives lots of power, but also lots of chances to mess it up and end up with a totally unmaintainable crap. Great power comes with great responsibility. Personally, I quite liked https://github.com/mattupstate/overholt (although some dependencies are out dated!). Also, having some starting point with the boilerplate code already in place helps you to prototype faster, etc.

Speaking of modules, the Flask modules ecosystem is pretty great and familiarizing yourself with it might save plenty of time you'd spend on re-implementing them. Some popular modules that are worth mentioning:

1) Flask-assets https://flask-assets.readthedocs.io/en/latest/ allows to easily integrate processing of the assets (JS minification, SASS compilation, etc) into your development pipeline;

2) Flask-login https://github.com/maxcountryman/flask-login simple users management (roles, authentication, etc.);

3) Flask-SQLAlchemy http://flask-sqlalchemy.pocoo.org/2.1/ simple integration with SQLAlchemy

4) Flask-Script https://flask-script.readthedocs.io/en/latest/ makes it easy to write command line tools which run in the context of Flask application (e.g. some cron jobs).

I also like https://github.com/svenstaro/flamejam/ as a good example of Flask architecture. It's simple and maintainable. I wrote a 4k+ loc app using a similar pattern and it still remains quite easy to handle.

I'm the author of that so if anyone has any questions feel free to shoot. Generally, the project is quite old but I still build flask application in quite the same manner as that. You can see the project running at https://bacongamejam.org

From the release notes, it appears flask.cli may be intended to replace Flask-Script (4): "Added flask and the flask.cli module to start the local debug server through the click CLI system. This is recommended over the old flask.run() method as it works faster and more reliable due to a different design and also replaces Flask-Script."

Yeah, forgot to mention it when writing :)

I've used some example architectures in the past while making a relatively small but very detail-oriented Flask app. I found that testing was a nightmare because my errors were only triggered on runtime. So I ended up having to manually test each code path in order to make sure I didn't have something as simple as a type error in my code. Static analysis helped a bit, but it's not as rigorous as a proper type system. Do you have any advice for this situation? It turned me off of web development in Python almost entirely.

What exactly do you mean by 'errors were only triggered on runtime'?

I'm not sure I really understand what you're saying, but in any case, this is a problem with any dynamically typed language, and isn't in any way specific to Flask or even Python. If writing applications without the guarantees of a "proper type system" is painful for you, then Python is probably the wrong language.

That said, you shouldn't have to manually test anything—that's what automated tests are for. With regard to testing Flask applications specifically, there is a guide[0] in the docs that covers everything you need to get started.

[0]: http://flask.pocoo.org/docs/0.11/testing/

Are you unit testing?

I wasn't, but I guess this is the only solution. The biggest reason I didn't unit test was that most of my functions were dependent on a significant amount of internal state. I suppose I should have spent more time coming up with mock models to use during unit tests. Also separating functionality would have made things easier.

This sounds more like an issue with the application design rather than Flask, Python, or even Web development. How easy or hard it is to test software is often a good indicator of the quality of the underlying design - if it is too hard to separate code into testable units and you have to mock loads of things to test for the most basic cases, there's a more fundamental problem somewhere. Of course, there are things that are hard to test, but it shouldn't be the whole application that is hard to test.

It sounds like you were doing two things that don't really work well in Python + framework environments in my experience:

1. Depending on internal state: I've always had a harder time working with state, regardless of language. I usually try to structure my code so that most of my business logic is encoded in functions that have inputs and outputs and don't modify any state. Only the toplevel functions modify the state, and they do so by applying database queries or updates that were generated functionally. This also can often drastically simplify or even eliminate your mocks.

2. Not unit testing. Without static types, it's pretty necessary to unit test. Think of it as that you test whether the types are correct by trying to use them in a trivial case. This is a double edged sword: on the one hand, unit tests give you more than static types: a type checker can tell you if the two things you're adding aren't numbers, but it can't tell you that you're adding the wrong numbers. The flipside is that nothing will tell you if you didn't test something, or didn't test it correctly.

I don't know if you'll have opportunity to try it again, but maybe next time try a test-driven development (TDD) approach where you define your function's interface (inputs and outputs) write failing tests that test those inputs and outputs, and then implement to make those tests pass. I don't encourage dogmatic TDD, but it can be a good starting point. Once you get a good feel for what kinds of interfaces are testable and where tests are helpful, you can scale back your testing a bit and test more pragmatically as needed.

This is called "writing tests".

Is there a decent Flask bootstrap? I've never been able to get in to Flask because there's so little provide out-of-the-box. I'd be looking for user accounts, admin, form handling, basic crud, sqlite, db schema/migrations.

I'd love a re-write of http://web2py.com that conforms to pythonista expectations.

That's Django. You'd pick Django for those, Flask if you don't need them or want to do them yourself. Werkzeug if you want to do even more yourself, which I have found useful on a couple occasions.

It's the flexibility versus batteries included tradeoff, and I don't think it's a negative that Flask doesn't ship most of that. You could probably somewhat get there with a number of third party additions (gedrap mentioned some) but you might as well use Django if you find yourself needing that stuff baked in.

There's also this skeleton for Google App Engine:

https://github.com/GoogleCloudPlatform/appengine-python-flas...

This got me going with Flask. It's not quite everything you asked for but it lays a foundation upon which to build and explore the different features you've listed. And App Engine's free tier provides a nice platform for prototyping and simplifies deployment.

You appear to be asking to turn Flask into Django, but this gets you most of the way on that specific list: - https://github.com/sloria/cookiecutter-flask

Big thumbs up to cookiecutter-flask. I've built several mid-size Flask apps with it over the past year or so, and I find that it lays a great foundation, for what is in my case a typical setup (e.g. Bootstrap based UI, SQLAlchemy based back-end, simple user accounts). It's well-maintained at the moment, too. When building a new app, first:

  cookiecutter https://github.com/sloria/cookiecutter-flask.git

Then customise all you want.

Please don't recommend Flask-Assets, JAC is so much better:

https://github.com/jaysonsantos/jinja-assets-compressor

Could you expand on why you think so?

Basically it's django-compressor[1] for Flask. That means automatic detection of static assets from your template files.

Flask-Assets makes you list every static file in a giant config, aka registering your assets in bundles. There is no need for that mess.

[1] https://django-compressor.readthedocs.io/en/latest/

Seconded. I ended up spending several days trying to re-organize my first decent-sized Flask project when I tried to add a different config for testing. On the next project I started with a template that handled the boilerplate bits like app factories and test structure and it went much smoother.

Reply on news.ycombinator.com