Pouring Django world into Flask

Przemek Lewandowski

@haxoza

One drop at a time - case study

About me

Overview

• Choosing the right tools
• Flask way
• Building basic API
• Flask vs Django

Feeding the troll
is not intended

Disclaimer

The project to build

• Scraping a few RSS feeds (10 rows/min)
• One bag of data
• Basic API with one endpoint
• One table view

Do we need a big framework for this?

Chosen toolset

• Flask
• PostgreSQL
• Celery
• Angular

Let's start with Flask!

Flask-SQLAlchemy

db = SQLAlchemy()


class Document(db.Model):
    id = Column(Integer(), primary_key=True)
    data = Column(MutableDict.as_mutable(JSONB), nullable=False)

    def __init__(self, data):
        self.data = data

flask-script as entry point

• migrations with Alembic
  • flask-migrate
• dev server
• tests entry point
• flask app creation

flask-script example

#!/usr/bin/env python

from flask.ext.script import Manager, Command
from flask.ext.migrate import MigrateCommand

from app import create_app
from grabber import grab_feeds
from tasks import run_celery
from tests.command import PytestCommand


manager = Manager(create_app)
manager.add_option('-c', '--config', dest='config_file', required=False)
manager.add_command('db', MigrateCommand)
manager.add_command('test', PytestCommand)
manager.add_command('runcelery', Command(run_celery))
manager.command(grab_feeds)

if __name__ == '__main__':
    manager.run()

flask app creation

def create_app(config_file=None, settings_override=None):
    app = Flask(__name__)

    if config_file:
        app.config.from_pyfile(config_file)
    else:
        app.config.from_envvar(config_variable_name)

    if settings_override:
        app.config.update(settings_override)

    init_app(app)

    return app


def init_app(app):
    db.init_app(app)
    migrate.init_app(app, db)
    api.init_app(app)

What about tests?

Issues with tests

• App initialization
• Test database
• Rollback after test
• HTTP client

py.test fixtures
to the rescue!

py.test app fixture

@pytest.yield_fixture(scope='session')
def app():
    app = create_app(config_file='config/testing.py')
    app.response_class = ApiTestingResponse
    ctx = app.app_context()
    ctx.push()

    yield app

    ctx.pop()

py.test db and client fixtures

@pytest.yield_fixture(scope='session')
def db(app):
    _db.create_all()

    yield _db

    _db.drop_all()


@pytest.fixture(scope='session')
def client(app):
    return app.test_client()

py.test db session fixture

@pytest.yield_fixture(scope='function')
def db_session(db):
    connection = db.engine.connect()
    transaction = connection.begin()

    options = dict(bind=connection)
    session = db.create_scoped_session(options=options)

    db.session = session

    yield session

    transaction.rollback()
    connection.close()
    session.remove()

Let's do REST API

Basic REST API

class FeedsResource(Resource):

    def get(self):
        # request parsing
        return {
            'data': 'transformed to json',
        }


api = FeedsApi()
api.add_resource(FeedsResource, '/feeds')

py.test with API

def test_get_should_return_feed_data(client, session):
    feed_entries_count = 3
    factories.FeedDataFactory.create_batch(feed_entries_count)

    response = client.get('/feeds')

    assert response.status_code == 200
    assert response.json['records_total'] == feed_entries_count
    assert len(response.json['data']) == feed_entries_count

Flask boilerplate

github.com/sunscrapers/flask-boilerplate

Flask vs Django

Django philosophy

• Loose coupling 
• Less code / Fullstack
• DRY
• Active Record design pattern

Common Django pitfalls

• Replacing default ORM
• Too fat models
• Business logic in forms / views
• Mixing application layers

Flask philosophy

• Small and simple core
• Flexibility
• No decisions for developers
  • No database layer
  • No form validations layer
  • ...

Common Flask pitfalls

• Reinventing the wheel
• First hours spent on basic stuff
• A need for your own conventions

Micro-frameworks encourage to

• Modular structure
• Design architecture from the beginning
• Omit pitfalls
  • i.e. Active Record pattern for bigger apps
• Use POPO (Plain Old Python Object)

Resources

• http://flask.pocoo.org/docs/0.10/foreword/#what-does-micro-mean
• https://docs.djangoproject.com/en/1.9/misc/design-philosophies/
  
• https://www.dabapps.com/blog/django-models-and-encapsulation/
  

Thanks!

Questions?

@haxoza