No-Cache headers in Flask

| Comments

The second line of “The Zen of Python” (try import this) says “Explicit is better than implicit.”. By default Flask response does not return any cache header and you can suppose that browsers will not cache, but some of them can decide for you. So it’s better to provide them, especially for API and it’s easy:

	@app.after_request
    def set_response_headers(response):
        response.headers['Cache-Control'] = 'no-cache, no-store, must-revalidate'
        response.headers['Pragma'] = 'no-cache'
        response.headers['Expires'] = '0'
        return response

Interesting articles

| Comments

Several interesting articles I found recently. Some of them I think from Dan Bader twitter.

Django vs Flask - a detailed comparison Django vs Flask.

In most cases I preferer Django.

  • It has better documentation
  • There are better apps in core, with Flask you need to search for an app, compare alternatives and sometimes they are not updated for a long time
  • You can choose which core apps to use
  • I think it’s better developed and supported

How the heck does async/await work in Python 3.5? - a long read about async in python

Using Docker for Flask Application Development (not just Production!) - i use it the same way, the only problem I have with Python development in Docker is debugging in Intellij Idea. There is a remote interpreter, but it does not work well for me, will try it again with the latest version.

Flask-RESTful migration to Flask-RESTPlus

| Comments

In a simple application with a several endpoints, it’s ok to use the default Flask routes.

@app.route('/api/v1.0/users', methods=['GET'])
def get_users():
    return jsonify({'objects': users})

But when an application becomes bigger, it can be useful to use a some REST framework or split it on the smaller apps. The REST framework is used to:

  • enforce best practices
  • simplify: versioning, serialization, documentation, authenication
  • provide browsable API

Migrations for MongoEngine

| Comments

A MongoDB collection does not have a strict schema, the documents in one collection can have different fields. But in MongoEngine the schema is provided on an application level and there is a validation. So if you’ll remove a field from the Document and it’s still exists in the database, there will be a mongoengine.errors.FieldDoesNotExist exception. If there is no need in the schema validation, a dynamic schema can be used.

So when there is a strict schema, it’s good to have a tool to make an updates for the documents in the collection when something changes.

« 2/3 »