DEV Community: Rittik Dasgupta

Writing a Flask App the !Noob Way

Rittik Dasgupta — Wed, 15 Sep 2021 21:33:09 +0000

This tutorial is not meant for beginners. It is assumed that the reader is familiar with the flask framework.

In this tutorial we will be writing a flask application using Flask Blueprints and Application Factory Pattern.

What are blueprints?

If you're working on a small project, keeping all of your code in one module isn't a bad idea. However, for large projects, it is usual practise to divide your project into numerous packages using Flask Blueprints.

A blueprint is a file that contains a single piece of functionality in your application. Consider a flask application built with blueprints as a collection of critical bits of functionality that work together to produce a complete web application.

It's a good idea to think about what blueprints you can break your application into before you start writing. I usually use three blueprints, api, user and admin, in my personal approach. The api blueprint is added to handle programmatic access to the web application resources. The user-related functionality is handled by the user blueprint, including registration, logout, login, password reset etc. The admin blueprint is in charge of the admin panel functionality and features.

|-app.py
|-.gitignore
|-README.md
|-requirements.txt
|-logs/
|-app_name/
    |-__init__.py
    |-.env
    |-models/
    |-utils/
    |-forms/
    |-config/
        |-config.py
        |-database.py
    |-static/
    |-templates/
        |-layout.html
        |-400.html
        |-403.html
        |-404.html
        |-405.html
        |-500.html
    |-routes/
        |-__init__.py
        |-api.py
        |-user.py
        |-admin.py
        |-templates
            |-user/
                |-register.html
            |-admin/
                |-panel.html

The following table gives an overview of what each file and folder does

File or Folder	Description
app.py	The file that contains the flask application instance for starting the application
requirements.py	The file that contains all the dependencies of the application
logs/	The folder that contains application logs
app_name/.env	"The file that contains environment variables like SECRET_KEY
app_name/routes	The folder that contains the blueprints and templates related to them
app_name/__init__.py	The file where we assemble the different components of the flask application
app_name/models/	The folder that contains the database models
app_name/utils/	The folder that contains the essential services like database access object (daos)
app_name/forms/	The folder that contains flask forms
app_name/config/config.py	The file that contains configurations of the flask application
app_name/config/database.py	The file that contains configurations of the database
app_name/static	"The folder that contains all the css
app_name/templates	The folder that contains the base template and error pages of the application

Because we've organised our application into blueprints, instead of sending requests to the flask application instance to be handled, the server now sends them to the appropriate blueprint. The blueprints must "register" with the flask application instance in order for the flask application instance to know about the project's blueprints and routes.

Configuration Management

There are several ways to configure a flask application, but in this tutorial we will be using an .env file and python objects.

In practise, you wouldn't want to hardcode the value of important parameters like the secret key, mail server username and password, and many more in the config.py file for security reasons.

The production-grade or the !noob way of setting important
parameters is to write them in an .env file. The python package python-dotenv is a handy little tool. After you've installed the package, you'll need to create a .env file in your project's root directory to define all of your environment variables. The load_dotenv() function in your config.py file is then used to load the environment configuration settings from the
.env file. You must remember to include the .env file to your .gitignore file if you use this technique.

Your .env file

CONFIG_ENV = Development
ENV = development
SECRET_KEY = 'DamnSIMpLeSecREtKEy'
DATABASE_URI = 
'mysql+pymysql://user:password@hostname:port/database_name'
MAIL_USERNAME = mail_user
MAIL_PASSWORD = mail_password
MAIL_DEFAULT_SENDER = mail_sender

Your config.py file

from os import path, environ 
from dotenv import load_dotenv

# Absolute path of app_name directory
BASE_DIR = path.abspath(path.dirname(path.dirname(__file__)))

# Loading configuration variable into the environment from .env file
load_dotenv(path.join(BASE_DIR, '.env'))

class Config:
    """
    Base class configuration, common to all other config classes
    """

    SECRET_KEY = environ.get('SECRET_KEY', 'samplesecret_key')
    WTF_CSRF_ENABLED = True
    SQLALCHEMY_TRACK_MODIFICATIONS = False
    MAIL_SERVER = 'smtp.googlemail.com'
    MAIL_USE_SSL = True
    MAIL_PORT = 465
    MAIL_USE_TLS = False
    MAIL_SUPPRESS_SEND = False
    MAIL_USERNAME = environ.get('MAIL_USERNAME', '')
    MAIL_PASSWORD = environ.get('MAIL_PASSWORD', '')
    MAIL_DEFAULT_SENDER = environ.get('MAIL_USERNAME', '')

class Development(Config):
   """Configuration settings for development environment"""
    DEBUG = True
    TESTING = False
    ENV = 'development'
    DATABASE_URI = environ.get("DATABASE_URI")

class Production(Config):
    """Configuration settings for production environment"""
    DEBUG = False
    TESTING = False
    ENV = 'production'
    DATABASE_URI = environ.get("PROD_DATABASE_URI")

class Testing(Config):
    """Configuration settings for testing environment"""
    TESTING = True
    WTF_CSRF_ENABLED = False
    MAIL_SUPPRESS_SEND = True
    DATABASE_URI = environ.get("TEST_DATABASE_URI")

Your app_name/__init__.py file

from flask import Flask
from os import environ
from .config.config import Development, Production

def create_app():

    app = Flask(__name__)

    if environ.get('CONFIG_ENV') == 'Development':
        app.config.from_object(Development())
    else:
        app.config.from_object(Production())

    @app.route("/",methods=['GET'])
    def index():
        return '<h2>App is Running</h2>'

    return app

Your app.py file

from os import environ
from app_name import create_app

app = create_app()

if __name__ == "__main__":
    app.run()

Creating Blueprints

Blueprints are defined by instantiating an instance of the Blueprint class. The arguments passed to the class constructor are the name of the blueprint and the name of the folder containing the templates belonging to the blueprint and a url prefix to differentiate between the similar routes of different blueprints. You then need to write the routes of that blueprint.

Your app_name/routes/api.py file

from flask import Blueprint

def create_blueprint():
    """Instantiating api blueprint and returning it"""

    api = Blueprint('api', __name__, 
    template_folder='templates', url_prefix='/api')

    @api.route('/info',methods=['GET'])
    def info():
        return '<h2>Sample Route</h2>'

    return api

Your app_name/routes/user.py file

from flask import Blueprint, render_template

def create_blueprint():
    """Instantiating user blueprint and returning it"""

    user = Blueprint('user', __name__, 
    template_folder='templates/user', url_prefix='/user')

    @user.route('/register',methods=['GET'])
    def register():
        return render_template('register.html')

    return user

Your app_name/routes/admin.py file

from flask import Blueprint, render_template

def create_blueprint():
    """Instantiating admin blueprint and returning it"""

    admin = Blueprint('admin', __name__, 
    template_folder='templates/admin', url_prefix='/admin')

    @admin.route('/panel',methods=['GET'])
    def panel():
        return render_template('panel.html')

    return admin

Important points to remember when working with blueprints

Any references to the app object must be replaced with references to the current_app object. This is because you no longer have direct access to the flask application instance when dealing with blueprints. It is only accessible through its proxy, current_app.
Make sure the url_for() method refers to the view function's blueprint. This is done to reflect the reality that certain blueprints have distinct view functionalities. url_for(user.register).
Make that the blueprint object is used by the decorator used to define any route.

Application Factory Pattern

We want to create flask applications with different configurations(Development, Production, Testing) without changing much in the actual code. Here, the function of factory method is to spin up different flask applications according to our need. The Application Factory Pattern is nothing but the well-known design pattern Factory Method Pattern.

Format to make an Application Factory Function

Instantiation of Flask Application
Loading Configurations of Flask Application
Registration of BLueprints
Registration of Error Handlers
Configuration of Logging Module

We covered the first two steps in the previous sections, so we will be continuing from the third step.

Registration of Blueprints

Blueprints are registered by passing the blueprint object to the register_blueprint() method the flask application instance exposes.

Your utils/register_blueprints.py file

from app_name.routes import user, admin, api

def register_blueprints(app):
    """Registering all the blueprint objects"""

    app.register_blueprint(user.create_blueprint())
    app.register_blueprint(admin.create_blueprint())
    app.register_blueprint(api.create_blueprint())

Your app_name/__init__.py file

from flask import Flask
from os import environ
from .config.config import Development, Production
from .utils.register_blueprints import register_blueprints

def create_app():

    app = Flask(__name__)

    if environ.get('CONFIG_ENV') == 'Development':
        app.config.from_object(Development())
    else:
        app.config.from_object(Production())


    # Registering Blueprints
    register_blueprints(app)


    @app.route("/",methods=['GET'])
    def index():
        return '<h2>App is Running</h2>'

    return app

What is Logging?

It is the process of keeping official record of your application. It is used for recording events as they occur and is a great tool for debugging any issues and gaining information about your application's working.

You should log application specific errors as well as database specific errors. You may also opt to log important functionalities of your application. Any kind of sensitive information should not be logged as logs are stored in plaintext format.

Logging Module

Generally standard python logging module is used. The standard looging module has 4 submodules, which are loggers, handlers, filters and formatters.

Loggers are the objects that create log messages. When you produce a log message, you have to specify its criticality by using the function associated with the criticality level.The following are the criticalility levels (also known as logging levels), their numeric representations, and the functions that go with them:

Debug → 10 → debug()
Info → 20 → info()
Warning → 30 → warning()
Error → 40 → error()
Critical → 50 → critical()

A default logger object can be accessed and utilised without the requirement for any configuration. The app.logger object is exposed by every flask instance. If you're using blueprints, you'll need to use the current_app object, which is a proxy for the flask application instance.

Your app_name/routes/admin.py file

from flask import Blueprint, render_template, current_app

def create_blueprint():
    """Instantiating admin blueprint and returning it"""

    admin = Blueprint('admin', __name__, 
    template_folder='templates/admin', url_prefix='/admin')

    @admin.route('/panel',methods=['GET'])
    def panel():
        current_app.logger.info("Admin Panel Accessed")
        return render_template('panel.html')

    return admin

The default logger, unfortunately, simply prints to the console. As a result, if you want to log to a file, you must create a new logger instance. The default logger will continue to log, but you can turn it off if you want:


from flask.logging import default_handler
app.logger.removeHandler(default_handler)

You can set the minimum criticality level of the messages that should be logged when configuring a new logger instance. All log messages with a criticality of this value or greater will be logged, while those with a criticality of less than this value will be ignored. This is handy in instances where you don't want
to delete log calls from your source code but still want to limit the number of log messages. You can increase the minimum log level of messages that are written to the log, such as ERROR messages and higher.

Handlers are the objects that route log messages to the appropriate location. A stream handler is the default handler, and it transmits log messages to the terminal. To route log messages to different destinations, you can build different handler objects.

A FileHandler is used to log to a file. A SMTPHandler is used to deliver log messages as email.
The FileHandler function accepts the location and name of the log file you wish to write to and creates a FileHandler object that sends log messages to that file.
In most cases, the logs folder is used to store files that execute during runtime (logs and database files). This folder must be added to your .gitignore file in order for version control to ignore it.


file_handler = logging.FileHandler('logs/application.log')
app.logger.addHandler(file_handler)

The log messages are written to a single log file via the FileHandler object. As a result, the log file might quickly grow in size. Using the RotatingFileHandler object is a better option. It likewise saves log messages to a file, but if the existing log file surpasses a certain size, it produces a new one (maxBytes). Before overwriting the current files, it will generate a new file up to a given number of files (backupCount).


from logging.handlers import RotatingFileHandler

file_handler = RotatingFileHandler('logs/application.log', maxBytes=16384, backupCount=15)

Filters are used to add contextual information to log messages. When logging requests, for example, you can add a filter that includes the request's external IP address.

Formatters are used to specify the format of the log messages. A LogRecord object represents each log message. Log formatters are used to specify which LogRecord characteristics should be displayed and in what order they should be displayed.

Some Attributes of LogRecords:

%(asctime)s - datetime when the LogRecord was created
%(filename)s - filename portion of pathname
%(funcName)s - name of function containing the logging call
%(levelname)s - logging level for the message
%(lineno)d - line number of source code where the logging call was issued (if available)
%(message)s - the logged message
%(module)s - module from which the logging call was issued

Configure Logging

You should configure logging before creating the flask application instance, otherwise it will use the default handler which writes log messages to the console. This is why the application factory function is used to configure logging.

Your utils/log_config.py file

import logging
from flask.logging import default_handler
from logging.handlers import RotatingFileHandler

def log_config(app):

    # Deactivate default flask logger 
    app.logger.removeHandler(default_handler)

    # File handler object
    file_handler = RotatingFileHandler('logs/application.log', maxBytes=16384, backupCount=15)

    # Set logging level of the file handler object so that it logs INFO and up
    file_handler.setLevel(logging.INFO)

    # file formatter object
    file_formatter = logging.Formatter('%(asctime)s %(levelname)s: %(message)s [in %(filename)s: %(lineno)d]')

    # Apply file formatter object to the file handler object

    file_handler.setFormatter(file_formatter)

    # Add file handler object to the logger
    app.logger.addHandler(file_handler)

Customized Error Handling

An HTTP status code is included in the response message when a client sends a request to a web server. It's a three-digit number that represents the outcome of the request processing. Based on the initial digit, status codes are divided into five categories, each representing a different type of response:

1xx — Informational response
2xx — Successful responses
- 200 (OK), for successful processing of the request
3xx — Redirects
- 302 (Found), for successfuly redirecting the client to a new URL
4xx — Client errors
- 400 (Bad Request): when the client makes a request that the server can’t understand or doesn’t allow.
- 403 (Forbidden): when the client tries to access a restricted resource and doesn’t have authorization to do so.
- 404 (Not Found): when a client requests a URL that the server does not recognise. The error message given should be something along the lines of “Sorry, what you are looking for just isn’t there!”.

405 (Method Not Allowed): when a request method is not accepted by the view function that handles requests for a given route. The error message given should be along the lines of “Sorry, the method requested is not supported by this resource!”.
1. 5xx — Server errors
500 (Internal Server Error): Usually occurs due to programming errors or the server getting overloaded.

Create your custom error pages eg: 403.html, 500.html, 404.html and then render these error pages using error_handlers.

Your utils/error_handlers.py file

def error_handlers(app):

    # 403 - Forbidden
    @app.errorhandler(403)
    def forbidden(e):
        return render_template('403.html'), 403

    # 400 - Bad Request
    @app.errorhandler(400)
    def bad_request(e):
        return render_template('400.html'), 400

    # 404 - Page Not Found
    @app.errorhandler(404)
    def page_not_found(e):
        return render_template('404.html'), 404

    # 405 - Method Not Allowed
    @app.errorhandler(405)
    def method_not_allowed(e):
        return render_template('405.html'), 405

    # 500 - Internal Server Error
    @app.errorhandler(500)
    def server_error(e):
        return render_template('500.html'), 500

Final app_name/__init__.py file

from flask import Flask
from os import environ
from .config.config import Development, Production
from .utils.register_blueprints import register_blueprints
from .utils.error_handlers import error_handlers
from .utils.log_config import log_config

def create_app():

    app = Flask(__name__)

    if environ.get('CONFIG_ENV') == 'Development':
        app.config.from_object(Development())
    else:
        app.config.from_object(Production())


    # Registering Blueprints
    register_blueprints(app)

    # Configure Logging
    log_config(app)

    # Registering Error Handlers
    error_handlers(app)

    @app.route("/",methods=['GET'])
    def index():
        return '<h2>App is Running</h2>'

    return app

Conclusion

You may now brag to your buddies about not being a noob flask developer.

I hope you all enjoyed the article.

Markdown Preview in Vim

Rittik Dasgupta — Thu, 15 Apr 2021 11:53:53 +0000

When we edit a markdown file in vim, we are not able to preview the markdown file simultaneously. I have also faced this situation, so I decided why not make one.

To be able to preview a markdown, first, we need a markdown parser.
I got to know about Glow, which renders markdown on the Command Line Interface(CLI).

To install glow, you can follow the instructions given in the Github repo of Glow.

After installing Glow I added a few lines to my vimrc

This function finds the path of the current file and adds it in the .lastpreview.log file. After that bel vert terminal command is executed, which opens up the terminal buffer in vim, side by side.

nmap <F4> : call PreviewerMarkdown()<CR>clear<CR>glo $(cat ~/.lastpreview.log)<CR>

Also, I made this custom mapping in vimrc. I bound my F4 key to the PreviewerMarkdown(). After PreviewerMarkdown is executed the clear command runs which clears the terminal buffer, and after this glo command runs, which is basically an alias I made for glow -s dark | less. The glo command opens the file path present in the lastpreview.log file with a pager (here less) and a suitable color scheme, and boom our markdown preview is now ready to be used.

There is room for adding more functionality to the PreviewerMarkdown(), but for this post, I chose to keep only the core functionality.

Overview of Vim

Rittik Dasgupta — Mon, 16 Nov 2020 11:58:51 +0000

What is Vi?

Vi was the first screen-oriented text editor created for Unix, it was designed to be simple yet powerful for text manipulation.

What is Vim(Vi IMproved)?

Vim is not just any text editor, it is an open-source configurable text editor that we can program according to our needs. It is an extremely fast and powerful text editor.

Philosophy of Vim

When programming, you spend most of your time reading/editing, not writing. For this reason, Vim is a modal editor: it has different modes for inserting text vs manipulating text. Vim is programmable (with Vimscript and also other languages like Python), and Vim’s interface itself is a programming language: keystrokes (with mnemonic names) are commands, and these commands are composable. Vim avoids the use of the mouse because it’s too slow; Vim even avoids using the arrow keys because it requires too much movement.
The end result is an editor that can match the speed at which you think.

Advantages of VIM

Vim is Always Available: Vim is available on most, if not all Linux distributions out there, you can install it from your distro’s official software repositories as follows:

apt-get install vim [On Debian/Ubuntu]
yum install vim [On RHEL/CentOS]
dnf install vim [Fedora 22+]

WSL and WSL2 can be used in Windows to be able to use VIM. Also, Vim GUI can be downloaded for Windows to use VIM. Click Here to download Vim GUI.

Vim Is Very Customizable and Extensible
Vim Uses Less Amount of System Resources
Vim Supports All Programming Languages and File Formats
Vim Has A Vibrant Community

Disadvantages of VIM

Difficult learning curve
High effort to customize

Modes in VIM

Vim’s design is based on the idea that a lot of programmer time is spent reading, navigating, and making small edits, as opposed to writing long streams of text. For this reason, Vim has multiple operating modes.

Normal: for moving around a file and making edits
Insert: for inserting text
Replace: for replacing text
Visual (plain, line, or block): for selecting blocks of text
Command-line: for running a command

My Opinion on Vim:

Stick with using vim for all your text editing needs (even if it slows you down initially). If you can cross the initial learning period then it could be a boon for you.