Accreditation Bodies
Accreditation Bodies
Accreditation Bodies
Supercharge your career with our Multi-Cloud Engineer Bootcamp
KNOW MOREFlask is a powerful Python web framework that allows developers to quickly build web applications with minimal boilerplate code. It is highly extensible and customizable, making it a favorite among developers. Whether you are a beginner to the Flask framework or an experienced professional, this interview guide is designed to boost your confidence and knowledge of the Flask framework. The questions are divided into separate sections like databases, HTTP methods, errors, python flasks, and flask applications. With Flask Interview Questions, you can be confident that you will be well-prepared for your next interview.
Filter By
Clear all
The “micro” means Flask aims to keep the core features simple but extensible. It is classified as a micro web framework because it does not require particular tools or libraries. It does not mean that our whole web application has to fit into a single Python module, nor does it imply that Flask is lacking some functionality. Although, it does not support database abstraction layer, form validation, or any other pre-existing third-party tools. But it supports extensions to which we can add features to our applications.
Expect to come across this popular question in Python Flask interview questions.
Flask Python comes with all the advantages of Python. Some of them are listed down below:
In Flask web applications, in order to manipulate databases, we can use SQL and Object Relational Mapping (ORM). An ORM makes writing SQL queries easier for a programmer, because it enables us to write queries in an object-oriented language, and then ORM automatically translates it to SQL and retrieves the result as an object. On the other hand, Flask-User makes use of DbAdapters to support different databases. It ships with an SQLDbAdapter to support a wide range of SQL databases via Flask-SQLAlchemy (Firebird, Microsoft SQL Server, MySQL, Oracle, PostgreSQL, SQLite, Sybase, and more). It ships with a MongoDbAdapter to support MongoDB databases via Flask-MongoEngine. Custom DbAdapters can be implemented to support other Databases.
Flask | Django |
| Flask is a Python web framework built for rapid development | Django is built for easy and simple projects |
| Beginners are likely to find Flask more straightforward and convenient | Django is a high-level Python Framework- when compared to Flask, it comes with a slightly steeper learning curve. Experienced developers might enjoy working with Django and understand its architecture and conventions are better |
| Flask is a lightweight framework that gives abundant features without external libraries and minimalist features | Django is a full-stack web framework that enables ready-to-use solutions with its batteries-included approach |
| Flask provides support for API | Django doesn’t have any support for API |
| Flask does not support dynamic HTML pages | Django offers dynamic HTML pages |
| Flask is a WSGI framework | Django is a Full Stack Web Framework |
| Flask offers a diversified working style | Django offers a Monolithic working style |
One of the functions in the flask.json module is jsonify(). It converts data to JSON format and encapsulates it in a Response object with the application/JSON mime-type. It's worth noting that jsonify is occasionally imported directly from the flask module rather than the flask itself. In other words, jsonify() is a Flask assist method for appropriately returning JSON data. jsonify() provides a Response object with the application/JSON mime-type set, whereas json.dumps() only returns a JSON data string. This could have unforeseen consequences.
In Flask, WTF stands for WT Forms, which is used to give the user an interactive user interface. The WTF is a flask built-in module that allows for a different way of constructing forms in flask web apps. WTForms may be easily integrated with Flask-WTF. Features included for Flask WTF are:
This is a frequently asked question in Flask Python interview questions.
Flask is a Flask addon that allows us to easily create APIs with a clean interface structure. It's an agile, quick, and lightweight abstraction that works with existing ORMs and frameworks.
If we understand the basics of Flask, we should find Flask-RESTful to be a simple idea to grasp. To create a REST API, we have to do the following steps:
Flask-Session is a Flask extension that adds server-side session functionality to your application. The Session is the period of time between when a client logs in and logs off of a server. The data that must be saved in the session is saved on the server in a temporary directory. We can utilize session objects in Flask whenever we need to save a large quantity of data between queries. The session object can be used to set and obtain data, as demonstrated below -
Clear allfrom flask import Flask, session
app = Flask(__name__)
@app.route('/use_session')
def use_session()
if 'song' not in session:
session['songs'] = {'title': Perfect, 'singer': 'Ed Sheeran'}
return session.get('songs')
@app.route('/delete_session')
def delete_session()
session.pop('song', None)
return "removed song from session" g is a global namespace that can be used to store any data during a single app context. A before request handler, for example, may set g.user, which the route and other functions will have access to. In the flask, on the other hand, a session object, which is a dictionary object that holds a key-value pair of the session variables and their associated values, is used to track the session data. To set the session variable to a specified value on the server, use the following syntax. We can use the session to save data for a specific browser. When a user of our Flask app makes more queries while using the same browser, the session data is carried over.
To send emails, run the following command to install the Flask-Mail flask extension:
pip install Flask-Mail
Next, we'll need to configure the Flask Config API to set up MAIL_SERVER, MAIL_PORT, MAIL_USERNAME, MAIL_PASSWORD, and so on. Then we must import the Message Class, instantiate it, and create a message object before using the mail.send() function to send the email.
The following is an example:
from flask_mail import Mail, Message
from flask import Flask
app = Flask(__name__)
mail = Mail(app)
@app.route("/mail")
def email():
msg = Message( "Hello Message", sender="admin@test.com", recipients=["to@test.com"])
mail.send(msg) A common question in Flask interview questions and answers; don't miss this one.
POST, GET, PUT, and DELETE is the most regularly used HTTP methods. These methods relate to the CRUD (create, read, update, and delete) activities. To retrieve data from a URL, HTTP techniques are utilized. The available methods are given below:
Flask framework allows its users to request databases in three ways. They are as follows:
Flask-Session is a Flask extension that adds server-side session functionality to our application. In Flask Python, a session is a feature that allows you to remember information from one request to the next. A signed cookie is used in a flask program so that the user can inspect and edit the contents of the session. The user can additionally change the sessions if and only if it has the secret key named Flask.secret_key. Flask is a tiny Python framework that works similarly to the MVC framework. As a result, MVC is the ideal choice for Flask.
Memory allocation is managed by the Flask Python memory management. In addition, there is an inbuilt garbage collector that recycles all unneeded memory to free up heap space. All objects and data structures are held together in Flask Python by a collection of private heap spaces. It is inaccessible to programmers. It is the interpreter's job to keep track of everything. Users can, however, access some of the tools through the core API. Its allocation is managed by the Flask Python memory management. In addition, there is an inbuilt garbage collector that recycles all unneeded memory to free up heap space.
Internally, Flask uses thread-local objects so that users do not have to transmit objects from function to function within a request to stay thread-safe. This method is beneficial, but it necessitates a proper request context for dependency injection or reusing code that uses a request-specific variable.
One of the most frequently posed Flask interview questions for freshers, be ready for it.
A validator simply takes an input, checks that it meets some criteria, such as a string length limit, and then returns. If the validation fails, a ValidationError is raised. This method is quite straightforward and adaptable, allowing you to link any number of validators onto fields. In Flask, the validators class of WTForm is listed below:
request.remote_addr is used to get visitor IP address in Flask. Here is an example:
from flask import request
from flask import jsonify
@app.route("/get_user_ip", methods=["GET"])
def get_user_ip():
return jsonify({'ip': request.remote_addr}), 200 When our application launches, for various reasons applications and servers may fail. It is very common to face exceptions in the production build. Sometimes our codebase is completely ok, although it can throw exceptions. You may be wondering, why does that happen? Some reasons behind server errors are given below:
That's just a small sample of the problems we could face. So, how do we deal with such a situation? If our application is running in production mode and an exception occurs, Flask will show us a very plain page and log the exception to the logger by default.
In the Flask application, when an error occurs, an HTTP status code will be returned. If the HTTP status code is between 400-499, that means the error occurs on the client-side data request. On the other hand, if the HTTP status code is between 500-599, then it means the error occurs on the server-side application.
When an error occurs with an HTTP status code, we can show custom error pages to the user with the help of error handlers. It can return responses when a certain type of error is occurred, which is similar to a function view that returns a response when the request URL is similar. It passes the object to handle the error, in most cases, it is an HTTPException.
Another thing to note is that the response's HTTP status code is not set to the error handler's code. When returning a response from the error handler, we must make sure to include that.
To deploy the python flask app on Heroku, follow the procedures outlined below:
Create a virtual environment with pipenv and install Flask and Gunicorn by running the command - $ pipenv install
Create a “Procfile” and write the following code - $ touch Procfile flask gunicorn
Create “runtime.txt” and write the following code - $ touch runtime.txt
Create a folder named “app” and enter the folder - $ mkdir app, $ cd app
Create a python file, “main.py” and enter the sample code - $ touch main.py
Get back to the previous directory “eflask”.Create a file“wsgi.py” and insert the following code - $ cd ../ , $ touch wsgi.py
Run the virtual environment - $ pipenv shell
Initialize an empty repo, add the files in the repo and commit all the changes - $ git init, $ git add
$ git commit -m "Initial Commit"
Login to heroku CLI using - heroku login
Now, Create a unique name for your Web app - $ heroku create eflask-app
Push your code from local to the heroku remote
$ git push heroku main
This question is a regular feature in interview questions on Flask, be ready to tackle it.
Flask makes it simple to manage uploaded files. Just remember to include the enctype="multipart/form-data" tag in your HTML form, or the browser will refuse to send your files. Uploaded files are kept in memory or on the filesystem in a temporary place. You may get to those files by looking at the request object's files attribute. Each file that is uploaded is saved in that dictionary. It has the same behavior as a typical Python file object, but it additionally provides a save() method that allows you to save the file to the server's filesystem. Here's a simple example to demonstrate how it works:
from flask import request[Text Wrapping Break][Text Wrapping Break]@app.route('/upload', methods=['GET', 'POST'])[Text Wrapping Break]def upload_file():[Text Wrapping Break] if request.method == 'POST':[Text Wrapping Break] f = request.files['the_file'][Text Wrapping Break] f.save('/var/www/uploads/uploaded_file.txt')The filename attribute can be used to determine how the file was named on the client before it was uploaded to your application. However, keep in mind that its value might be faked, so don't put your faith in it. If you wish to utilize the client's filename to store the file on the server, you can use the secure filename() function that Werkzeug provides:
from werkzeug.utils import secure_filename[Text Wrapping Break][Text Wrapping Break]@app.route('/upload', methods=['GET', 'POST'])[Text Wrapping Break]def upload_file():[Text Wrapping Break] if request.method == 'POST':[Text Wrapping Break] file = request.files['the_file'][Text Wrapping Break] file.save(f"/var/www/uploads/{secure_filename(file.filename)}") Expect to come across this popular question in interview questions on Flask.
You can find yourself in a position where you're dealing with data that should be correct but isn't. For example, you might have some client-side code that sends a faulty HTTP request to the server. This could be due to tampering with the data by a user or a bug in the client code. In most cases, responding with 400 Bad Request is sufficient, but this isn't always the case, and the code must continue to function.
You might still wish to note that something unusual occurred. Loggers come in handy in this situation. With Flask 0.3, you can utilize a logger that has been preconfigured for you.
The following are some examples of log calls:
app.logger.debug('A value for debugging')[Text Wrapping Break]app.logger.warning('A warning occurred (%d apples)', 42)[Text Wrapping Break]app.logger.error('An error occurred') To protect against injection attacks, any user-provided values rendered in the output must be enclosed when returning HTML (the default response type in Flask). This will be done automatically using HTML templates produced with Jinja.
The escape() function, which is seen below, can be used manually. Most examples remove it for brevity's sake, but you should constantly be conscious of how you're employing untrustworthy data.
from markupsafe import escape[Text Wrapping Break][Text Wrapping Break]@app.route("/<name>")[Text Wrapping Break]def hello(name):[Text Wrapping Break] return f"Hello, {escape(name)}!"If a user enters the name <script>alert("bad")</script>, it is rendered as text rather than running the script in the user's browser due to escaping.
We use the url_for() function to create a URL for a given function. It takes the function's name as the first parameter, as well as any number of keyword arguments, each of which corresponds to a variable component of the URL rule. As query parameters, unknown variable bits are appended to the URL.
Blueprints: A Blueprint is a method of organizing a collection of related views and other code. Instead of registering views and other code with an application directly, they are registered with a blueprint. When the blueprint is available in the factory function, it is then registered with the application. Flask will have two blueprints, one for authentication and the other for blog postings. Each blueprint's code will be kept in its own module.
Views: The code you write to reply to queries to your application is known as a view function. Flask matches the incoming request URL to the view that should handle it using patterns. Flask converts the data returned by the view into an outgoing response. Flask may also generate a URL for a view depending on its name and arguments in the other direction.
Autoescaping is the concept of having special characters automatically escape for you. &, >, <, ", and ' are special characters in the context of HTML (or XML, and thus XHTML). If you want to use these characters in the text, you must replace them with so-called "entities" because they have special meanings in documents on their own. Not doing so would not only frustrate users by preventing them from using certain characters in the text, but it might also lead to security issues. (For further information, see Cross-Site Scripting (XSS)).
However, you may need to disable autoescaping in templates on occasion. This is true if you want to inject HTML into sites explicitly, such as when they come from a system that generates secure HTML, such as a markdown to HTML converter.
There are three options for doing so:
You can use the {% autoescape %} block to disable the autoescape system in templates:[Text Wrapping Break]
{% autoescape false %}[Text Wrapping Break] <p>autoescaping is disabled here[Text Wrapping Break] <p>{{ will_not_be_escaped }}[Text Wrapping Break]{% endautoescape %}Please be very careful about the variables you use in this block whenever you do this.
Signals allow you to decouple apps by sending notifications when activities in the core framework or other Flask extensions occur. In a nutshell, signals allow particular senders to alert subscribers to an event.
Flask comes with a few signals, and other extensions may add more. Keep in mind that signals are meant to alert subscribers and should not be used to urge them to change their data. You'll notice that several signals appear to accomplish the same thing as some of the built-in decorators (for example, request started looks a lot like before request()). There are, however, variances in how they operate. The before request() handler, for example, is called in a certain order and can cancel a request by returning a response early. All signal handlers, on the other hand, run in an indeterminate order and do not affect any data.
Signals have a significant advantage over handlers in that you can safely subscribe to them for a fraction of a second. These temporary subscriptions are useful for things like unit testing. If you want to know which templates were rendered as part of a request, you can use signals to accomplish so.
Creating Signals: You can use the blinker library directly if you wish to use signals in your own application. Named signals in a custom Namespace are the most prevalent use case. Most of the time, this is what is suggested:
from blinker import Namespace[Text Wrapping Break]my_signals = Namespace()
You can now generate new signals such as this:
model_saved = my_signals.signal('model-saved')The signal's name makes it stand out and makes debugging easier. The name attribute gives you access to the signal's name.
A common question in Flask interview questions, don't miss this one.
It makes little sense to decorate the view class itself because it is not the view function that is introduced to the routing system. Instead, you'll have to hand-decorate the as_view() return value:
def user_required(f):[Text Wrapping Break] """Checks whether user is logged in or raises error 401."""[Text Wrapping Break] def decorator(*args, **kwargs):[Text Wrapping Break] if not g.user:[Text Wrapping Break] abort(401)[Text Wrapping Break] return f(*args, **kwargs)[Text Wrapping Break] return decorator[Text Wrapping Break][Text Wrapping Break]view = user_required(UserAPI.as_view('users'))[Text Wrapping Break]app.add_url_rule('/users/', view_func=view)Starting with Flask 0.8, you can also specify a list of decorators to use in the class declaration:
class UserAPI(MethodView):[Text Wrapping Break] decorators = [user_required]
Keep in mind that you can't use conventional view decorators on the individual methods of the view because of the implicit self from the caller's perspective.
During a request, CLI command, or other activity, the application context keeps track of application-level data. The current app and g proxies are used instead of passing the application around to each function.
This is similar to The Request Context. The Request Context, which keeps track of request-level data during a request, is comparable to this. When a request context is pushed, it is accompanied by an application context.
Purpose of Application Context: Aspects of the Flask application object, such as config, can be accessed via views and CLI commands. Importing the app instance into your project's modules, on the other hand, is prone to circular import difficulties. There will be no app instance to import when using the app factory pattern or developing reusable blueprints or extensions.
The application context in Flask overcomes this problem. Instead of referring to an app directly, you use the current_app proxy, which points to the application that is now handling the action.
When handling a request, Flask automatically pushes an application context. current_app will be accessible to view functions, error handlers, and other functions that run during a request.
Application Context Lifetime: As needed, the application context is generated and removed. A Flask application pushes an application context and a request context when it starts handling a request. When the request is completed, the request context is displayed, followed by the application context. An application context usually lasts the same amount of time as a request.
For creating application components and enabling common patterns within and between applications, Flask employs the concept of blueprints. Blueprints can help huge applications run more smoothly by providing a central location for Flask extensions to register activities on them. A Blueprint object is comparable to a Flask application object in functionality, but it is not one. It's more of a template on how to build or enhance an application.
Blueprints in Flask are designed for the following scenarios:
This is an example of a very basic blueprint. In this scenario, we'd like to create a blueprint that renders static templates simply:
from flask import Blueprint, render_template, abort[Text Wrapping Break]from jinja2 import TemplateNotFound[Text Wrapping Break][Text Wrapping Break]simple_page = Blueprint('simple_page', __name__,[Text Wrapping Break] template_folder='templates')[Text Wrapping Break][Text Wrapping Break]@simple_page.route('/', defaults={'page': 'index'})[Text Wrapping Break]@simple_page.route('/<page>')[Text Wrapping Break]def show(page):[Text Wrapping Break] try:[Text Wrapping Break] return render_template(f'pages/{page}.html')[Text Wrapping Break] except TemplateNotFound:[Text Wrapping Break] abort(404)When you use the @simple_page.route decorator to bind a function, the blueprint records your intent to have the function show up on the app when it's later registered. In addition, the endpoint of the method will be prefixed with the name of the blueprint that was sent to the Blueprint constructor (in this case, simple_page). The name of the blueprint does not change the URL, simply the endpoint.
There are a few of really good ways to improve the experience if you're already utilizing packages and blueprints for your application (Modular Applications with Blueprints). When the blueprint is imported, a common pattern is to create the application object. You can make additional copies of this app later if you move the creation of this object into a function.
So, why would you want to do something like this?
So, how would you go about putting that into practice? Well, the idea is to set up the application in a function which we call Application Factories
def create_app(config_filename):[Text Wrapping Break] app = Flask(__name__)[Text Wrapping Break] app.config.from_pyfile(config_filename)[Text Wrapping Break][Text Wrapping Break] from yourapplication.model import db[Text Wrapping Break] db.init_app(app)[Text Wrapping Break][Text Wrapping Break] from yourapplication.views.admin import admin[Text Wrapping Break] from yourapplication.views.frontend import frontend[Text Wrapping Break] app.register_blueprint(admin)[Text Wrapping Break] app.register_blueprint(frontend)[Text Wrapping Break][Text Wrapping Break] return app
The disadvantage is that you can't use the application object in blueprints when they're being imported. However, you can utilize it within a request. With the config, how do you gain access to the application? Make use of current_app:\
from flask import current_app, Blueprint, render_template[Text Wrapping Break]admin = Blueprint('admin', __name__, url_prefix='/admin')[Text Wrapping Break][Text Wrapping Break]@admin.route('/')[Text Wrapping Break]def index():[Text Wrapping Break] return render_template(current_app.config['INDEX_TEMPLATE']) On the WSGI level, application dispatching is the process of joining numerous Flask apps. You can mix and match any WSGI application, not only Flask. If you like, you can run a Django and a Flask application in the same interpreter at the same time. This is only useful if you know how the programs function within.
The main distinction between this and Large Applications as Packages is that you're running the same or different Flask applications that are completely separate from one another. They are dispatched on the WSGI level and run distinct configurations.
Each technique and example below produces an application object that may be run on any WSGI server. See Deployment Options for production options. Werkzeug provides a server for development via werkzeug.serving.run_simple():
from werkzeug.serving import run_simple[Text Wrapping Break]run_simple('localhost', 5000, application, use_reloader=True)It's worth noting that run simply isn't meant to be used in production. Make use of a production-ready WSGI server. See Deployment Options for more information.
Debugging must be enabled on both the application and the simple server in order to use the interactive debugger. The "hello world" example with debugging and run_simple is as follows:
from flask import Flask[Text Wrapping Break]from werkzeug.serving import run_simple[Text Wrapping Break][Text Wrapping Break]app = Flask(__name__)[Text Wrapping Break]app.debug = True[Text Wrapping Break][Text Wrapping Break]@app.route('/')[Text Wrapping Break]def hello_world():[Text Wrapping Break] return 'Hello World!'[Text Wrapping Break][Text Wrapping Break]if __name__ == '__main__':[Text Wrapping Break] run_simple('localhost', 5000, app,[Text Wrapping Break] use_reloader=True, use_debugger=True, use_evalex=True) URL processors are a new feature in Flask 0.7. The notion is that you may have a collection of resources with similar components in the URL that you don't always want to supply explicitly. For example, you might have a bunch of URLs with language code in them, but you don't want to have to deal with it in each and every function.
When used in conjunction with blueprints, URL processors are extremely useful. We'll deal with both application-specific URL processors and blueprint specifics here.
Internationalized Blueprint URLs: It's simple to prefix all URLs with a common string using blueprints, and it's trivial to do so for every function. Furthermore, blueprints can contain per-blueprint URL processors, which takes a lot of complexity from the url_defaults() function by eliminating the need to check if the URL is truly interested in the 'lang_code' parameter:
from flask import Blueprint, g[Text Wrapping Break][Text Wrapping Break]bp = Blueprint('frontend', __name__, url_prefix='/<lang_code>')[Text Wrapping Break][Text Wrapping Break]@bp.url_defaults[Text Wrapping Break]def add_language_code(endpoint, values):[Text Wrapping Break] values.setdefault('lang_code', g.lang_code)[Text Wrapping Break][Text Wrapping Break]@bp.url_value_preprocessor[Text Wrapping Break]def pull_lang_code(endpoint, values):[Text Wrapping Break] g.lang_code = values.pop('lang_code')[Text Wrapping Break][Text Wrapping Break]@bp.route('/')[Text Wrapping Break]def index():[Text Wrapping Break] ...[Text Wrapping Break][Text Wrapping Break]@bp.route('/about')[Text Wrapping Break]def about():[Text Wrapping Break] ... This is a frequently asked question in interview questions on Flask for experienced.
If Flask is installed with the async extra, routes, error handlers, before request, after request, and teardown methods can all be coroutine functions (pip install flask[async]). Where ContextVars are used, Python 3.7 or above is required. ContextVar is a variable that can be used. Async def and await can now be used to define views.
@app.route("/get-data")[Text Wrapping Break]async def get_data():[Text Wrapping Break] data = await async_db_query(...)[Text Wrapping Break] return jsonify(data)Coroutine-based handlers are also supported by pluggable class-based views. This is true for views that inherit from the flask.views' dispatch_request() method. All HTTP method handlers in views that inherit from flask.views, as well as the View class. MethodView is a class that represents a method.
The execution of async functions necessitates the use of an event loop. As a WSGI application, Flask employs a single worker to manage a single request/response cycle. When an async view receives a request, Flask creates an event loop in a thread, runs the view function there, and then returns the result.
Even for async views, each request ties up one worker. On the plus side, you may use async code within a view to perform numerous concurrent database queries, HTTP connections to an external API, and so on. However, the maximum number of requests your application can manage at any given time will not change.
Async code isn't always faster than sync code. When doing concurrent IO-bound work, async is useful, but it is unlikely to improve CPU-bound operations. Traditional Flask views will continue to be appropriate for the majority of use cases, but Flask's async support allows you to write and use code that wasn't previously possible.
When to use Quart instead: Because of the way Flask's async support is designed, it is slower than async-first frameworks. It makes sense to investigate Quart if your codebase is primarily async. Quart is a Flask reimplementation based on the ASGI standard rather than the WSGI standard. This enables it to manage a large number of concurrent requests, long-running requests, and WebSockets without the need for many worker processes or threads.
Many of the benefits of async request handling can also be obtained by running Flask with Gevent or Eventlet. To do this, these libraries tweak low-level Python methods, whereas async/ await and ASGI make use of regular, current Python features. Understanding the individual needs is the most important factor in deciding whether to utilize Flask, Quart or something else.
Setuptools is a Python extension library for distributing Python libraries and extensions. It enhances distutils, a rudimentary module installation system included with Python, to include a number of more complicated operations that make it easier to distribute larger applications:
Setuptools or distutils are used to distribute Flask and all of the libraries available on PyPI. If you have already installed Flask, then you also have setuptools available on your system because Flask is dependable on setuptools. A Flask application's basic setup.py file looks like this:
from setuptools import setup[Text Wrapping Break][Text Wrapping Break]setup([Text Wrapping Break] name='Your Application',[Text Wrapping Break] version='1.0',[Text Wrapping Break] long_description=__doc__,[Text Wrapping Break] packages=['yourapplication'],[Text Wrapping Break] include_package_data=True,[Text Wrapping Break] zip_safe=False,[Text Wrapping Break] install_requires=['Flask'][Text Wrapping Break])
Please keep in mind that you must explicitly list subpackages. You can use the find packages method to have setuptools hunt up the packages for you automatically:
from setuptools import setup, find_packages[Text Wrapping Break][Text Wrapping Break]setup([Text Wrapping Break] ...[Text Wrapping Break] packages=find_packages()[Text Wrapping Break])
Fabric is a Python program that works similarly to Makefiles but also allows you to run commands on a remote server. Flask applications may be easily deployed to other servers when used in conjunction with a well configured Python package (Large Applications as Packages) and a good configuration concept (Configuration Handling).
Before we get started, here's a quick rundown of what we need to be sure of:
Create a simple Fabfile: Fabric's execution is controlled by a fabfile. It's called fabfile.py, and it's run with the fab program. All of the functions in that file will be available as fab subcommands. They are run on a single or several hosts. These hosts can be specified on the command line or in the fabfile. We'll add them to the fabfile in this scenario.
This is a simple initial example that allows you to upload current source code to the server and install it into a virtual environment that already exists:
from fabric.api import *[Text Wrapping Break][Text Wrapping Break]# the user to use for the remote commands[Text Wrapping Break]env.user = 'appuser'[Text Wrapping Break]# the servers where the commands are executed[Text Wrapping Break]env.hosts = ['server1.example.com', 'server2.example.com'][Text Wrapping Break][Text Wrapping Break]def pack():[Text Wrapping Break] # build the package[Text Wrapping Break] local('python setup.py sdist --formats=gztar', capture=False)[Text Wrapping Break][Text Wrapping Break]def deploy():[Text Wrapping Break] # figure out the package name and version[Text Wrapping Break] dist = local('python setup.py --fullname', capture=True).strip()[Text Wrapping Break] filename = f'{dist}.tar.gz'[Text Wrapping Break][Text Wrapping Break] # upload the package to the temporary folder on the server[Text Wrapping Break] put(f'dist/{filename}', f'/tmp/{filename}')[Text Wrapping Break][Text Wrapping Break] # install the package in the application's virtualenv with pip[Text Wrapping Break] run(f'/var/www/yourapplication/env/bin/pip install /tmp/{filename}')[Text Wrapping Break][Text Wrapping Break] # remove the uploaded package[Text Wrapping Break] run(f'rm -r /tmp/{filename}')[Text Wrapping Break][Text Wrapping Break] # touch the .wsgi file to trigger a reload in mod_wsgi[Text Wrapping Break] run('touch /var/www/yourapplication.wsgi')So, how do you put that fabfile into action? The fab command is what you use. This command would be used to deploy the current version of the code to the remote server:
$ fab pack deploy
How to redirect a user to another endpoint? Explain how to handle errors for redirecting a user.
Use the redirect() function to send a user to another endpoint; use the abort() function to abort a request early with an error code:
from flask import abort, redirect, url_for[Text Wrapping Break][Text Wrapping Break]@app.route('/')[Text Wrapping Break]def index():[Text Wrapping Break] return redirect(url_for('login'))[Text Wrapping Break][Text Wrapping Break]@app.route('/login')[Text Wrapping Break]def login():[Text Wrapping Break] abort(401)[Text Wrapping Break] this_is_never_executed()Because a user will be diverted from the index to a page they cannot access (401 denotes access forbidden), this is a fairly worthless example, but it demonstrates how it works.
For each error code, a black and white error page is displayed by default. You may use the errorhandler() decorator to personalize the error page:
from flask import render_template[Text Wrapping Break][Text Wrapping Break]@app.errorhandler(404)[Text Wrapping Break]def page_not_found(error):[Text Wrapping Break] return render_template('page_not_found.html'), 404Take note of the 404 that appears following the render template() function. This tells Flask that the page's status code should be 404, which stands for "not found." By default, the value 200 is assumed, which means that everything went smoothly.
It's no surprise that this one pops up often in Flask interview questions for experienced.
Most error handlers will operate as expected in Modular Applications with Blueprints. There is a caveat, though, when it comes to handlers for 404 and 405 errors. These error handlers are only called when there is an appropriate raise statement or a call to abort in one of the blueprint's view functions; they are not called when there is invalid URL access, for example.
Because the blueprint does not own a certain URL space, the application instance has no means of knowing which blueprint error handler to apply if the URL is wrong. If you want to use alternative handling strategies for these errors based on URL prefixes, you can do so using the request proxy object at the application level.
from flask import jsonify, render_template[Text Wrapping Break][Text Wrapping Break]# at the application level[Text Wrapping Break]# not the blueprint level[Text Wrapping Break]@app.errorhandler(404)[Text Wrapping Break]def page_not_found(e):[Text Wrapping Break] # if a request is in our blog URL space[Text Wrapping Break] if request.path.startswith('/blog/'):[Text Wrapping Break] # we return a custom blog 404 page[Text Wrapping Break] return render_template("blog/404.html"), 404[Text Wrapping Break] else:[Text Wrapping Break] # otherwise we return our generic site-wide 404 page[Text Wrapping Break] return render_template("404.html"), 404[Text Wrapping Break][Text Wrapping Break]@app.errorhandler(405)[Text Wrapping Break]def method_not_allowed(e):[Text Wrapping Break] # if a request has the wrong method to our API[Text Wrapping Break] if request.path.startswith('/api/'):[Text Wrapping Break] # we return a json saying so[Text Wrapping Break] return jsonify(message="Method Not Allowed"), 405[Text Wrapping Break] else:[Text Wrapping Break] # otherwise we return a generic site-wide 405 page[Text Wrapping Break] return render_template("405.html"), 405 Flask began as a demonstration of how to create your own framework using well-known tools like Werkzeug (WSGI) and Jinja (templating), but as it grew in popularity, it became helpful to a broader audience. Don't just utilize Flask as you expand your codebase; learn it. Check out the source. Flask's code is written to be read, and its documentation is available for users with its internal APIs. Flask follows upstream libraries' defined APIs and describes its internal utilities so you can locate the hook points you need for your project.
Hook and Extend: The API documentation is full of overrides, hook points, and Signals. Custom classes can be provided for request and response objects, for example. Look at the APIs you're using and see what customizations are available right out of the box in a Flask release. Look for ways to rework your project into a collection of Flask extensions and utilities. If you can't discover what you're looking for among the many Extensions in the community, seek for patterns to develop your own.
Subclass: Many methods of the Flask class are intended for subclassing. Subclassing Flask (see the linked method instructions) and using that subclass anywhere you instantiate an application class allows you to rapidly add or alter behavior. This is a great way to use Application Factories. For an example, see Flask Subclassing.
Wrap with middleware: The Application Dispatching pattern explains how to use middleware in detail. To encapsulate your Flask instances and introduce repairs and updates at the layer between your Flask application and your HTTP server, you can use WSGI middleware. Werkzeug comes with a number of middlewares.
Fork: Fork Flask if none of the preceding options work. Werkzeug and Jinja2 contain the majority of Flask's code. The majority of the work is done by these libraries. Flask is simply the glue that holds them together. Every project has a moment where the underlying framework becomes a hindrance (due to assumptions the original developers had). This is understandable because if it weren't, the framework would be an extremely complex system from the start, resulting in a steep learning curve and a lot of user irritation.
For many online applications, code complexity is less of a concern than scaling for the expected number of users or data entries. Flask's scalability capabilities are restricted solely by your application code, the data store you choose to utilize, and the Python implementation and web server you're using.
Scaling well means, for example, that doubling the number of servers yields roughly double the performance. Scaling poorly means that adding a new server will not improve performance or will not even support a second server. In Flask, the context local proxies are the only limiting element in terms of scaling. They are dependent on context, which is defined in Flask as a thread, process, or greenlet. Flask will no longer be able to support global proxies if your server uses a concurrency model that isn't based on threads or greenlets. However, the majority of servers achieve concurrency by using threads, greenlets, or different processes, all of which are fully supported by the Werkzeug framework.
The “micro” means Flask aims to keep the core features simple but extensible. It is classified as a micro web framework because it does not require particular tools or libraries. It does not mean that our whole web application has to fit into a single Python module, nor does it imply that Flask is lacking some functionality. Although, it does not support database abstraction layer, form validation, or any other pre-existing third-party tools. But it supports extensions to which we can add features to our applications.
Expect to come across this popular question in Python Flask interview questions.
Flask Python comes with all the advantages of Python. Some of them are listed down below:
In Flask web applications, in order to manipulate databases, we can use SQL and Object Relational Mapping (ORM). An ORM makes writing SQL queries easier for a programmer, because it enables us to write queries in an object-oriented language, and then ORM automatically translates it to SQL and retrieves the result as an object. On the other hand, Flask-User makes use of DbAdapters to support different databases. It ships with an SQLDbAdapter to support a wide range of SQL databases via Flask-SQLAlchemy (Firebird, Microsoft SQL Server, MySQL, Oracle, PostgreSQL, SQLite, Sybase, and more). It ships with a MongoDbAdapter to support MongoDB databases via Flask-MongoEngine. Custom DbAdapters can be implemented to support other Databases.
Flask | Django |
| Flask is a Python web framework built for rapid development | Django is built for easy and simple projects |
| Beginners are likely to find Flask more straightforward and convenient | Django is a high-level Python Framework- when compared to Flask, it comes with a slightly steeper learning curve. Experienced developers might enjoy working with Django and understand its architecture and conventions are better |
| Flask is a lightweight framework that gives abundant features without external libraries and minimalist features | Django is a full-stack web framework that enables ready-to-use solutions with its batteries-included approach |
| Flask provides support for API | Django doesn’t have any support for API |
| Flask does not support dynamic HTML pages | Django offers dynamic HTML pages |
| Flask is a WSGI framework | Django is a Full Stack Web Framework |
| Flask offers a diversified working style | Django offers a Monolithic working style |
One of the functions in the flask.json module is jsonify(). It converts data to JSON format and encapsulates it in a Response object with the application/JSON mime-type. It's worth noting that jsonify is occasionally imported directly from the flask module rather than the flask itself. In other words, jsonify() is a Flask assist method for appropriately returning JSON data. jsonify() provides a Response object with the application/JSON mime-type set, whereas json.dumps() only returns a JSON data string. This could have unforeseen consequences.
In Flask, WTF stands for WT Forms, which is used to give the user an interactive user interface. The WTF is a flask built-in module that allows for a different way of constructing forms in flask web apps. WTForms may be easily integrated with Flask-WTF. Features included for Flask WTF are:
This is a frequently asked question in Flask Python interview questions.
Flask is a Flask addon that allows us to easily create APIs with a clean interface structure. It's an agile, quick, and lightweight abstraction that works with existing ORMs and frameworks.
If we understand the basics of Flask, we should find Flask-RESTful to be a simple idea to grasp. To create a REST API, we have to do the following steps:
Flask-Session is a Flask extension that adds server-side session functionality to your application. The Session is the period of time between when a client logs in and logs off of a server. The data that must be saved in the session is saved on the server in a temporary directory. We can utilize session objects in Flask whenever we need to save a large quantity of data between queries. The session object can be used to set and obtain data, as demonstrated below -
from flask import Flask, session
app = Flask(__name__)
@app.route('/use_session')
def use_session()
if 'song' not in session:
session['songs'] = {'title': Perfect, 'singer': 'Ed Sheeran'}
return session.get('songs')
@app.route('/delete_session')
def delete_session()
session.pop('song', None)
return "removed song from session" g is a global namespace that can be used to store any data during a single app context. A before request handler, for example, may set g.user, which the route and other functions will have access to. In the flask, on the other hand, a session object, which is a dictionary object that holds a key-value pair of the session variables and their associated values, is used to track the session data. To set the session variable to a specified value on the server, use the following syntax. We can use the session to save data for a specific browser. When a user of our Flask app makes more queries while using the same browser, the session data is carried over.
To send emails, run the following command to install the Flask-Mail flask extension:
pip install Flask-Mail
Next, we'll need to configure the Flask Config API to set up MAIL_SERVER, MAIL_PORT, MAIL_USERNAME, MAIL_PASSWORD, and so on. Then we must import the Message Class, instantiate it, and create a message object before using the mail.send() function to send the email.
The following is an example:
from flask_mail import Mail, Message
from flask import Flask
app = Flask(__name__)
mail = Mail(app)
@app.route("/mail")
def email():
msg = Message( "Hello Message", sender="admin@test.com", recipients=["to@test.com"])
mail.send(msg) A common question in Flask interview questions and answers; don't miss this one.
POST, GET, PUT, and DELETE is the most regularly used HTTP methods. These methods relate to the CRUD (create, read, update, and delete) activities. To retrieve data from a URL, HTTP techniques are utilized. The available methods are given below:
Flask framework allows its users to request databases in three ways. They are as follows:
Flask-Session is a Flask extension that adds server-side session functionality to our application. In Flask Python, a session is a feature that allows you to remember information from one request to the next. A signed cookie is used in a flask program so that the user can inspect and edit the contents of the session. The user can additionally change the sessions if and only if it has the secret key named Flask.secret_key. Flask is a tiny Python framework that works similarly to the MVC framework. As a result, MVC is the ideal choice for Flask.
Memory allocation is managed by the Flask Python memory management. In addition, there is an inbuilt garbage collector that recycles all unneeded memory to free up heap space. All objects and data structures are held together in Flask Python by a collection of private heap spaces. It is inaccessible to programmers. It is the interpreter's job to keep track of everything. Users can, however, access some of the tools through the core API. Its allocation is managed by the Flask Python memory management. In addition, there is an inbuilt garbage collector that recycles all unneeded memory to free up heap space.
Internally, Flask uses thread-local objects so that users do not have to transmit objects from function to function within a request to stay thread-safe. This method is beneficial, but it necessitates a proper request context for dependency injection or reusing code that uses a request-specific variable.
One of the most frequently posed Flask interview questions for freshers, be ready for it.
A validator simply takes an input, checks that it meets some criteria, such as a string length limit, and then returns. If the validation fails, a ValidationError is raised. This method is quite straightforward and adaptable, allowing you to link any number of validators onto fields. In Flask, the validators class of WTForm is listed below:
request.remote_addr is used to get visitor IP address in Flask. Here is an example:
from flask import request
from flask import jsonify
@app.route("/get_user_ip", methods=["GET"])
def get_user_ip():
return jsonify({'ip': request.remote_addr}), 200 When our application launches, for various reasons applications and servers may fail. It is very common to face exceptions in the production build. Sometimes our codebase is completely ok, although it can throw exceptions. You may be wondering, why does that happen? Some reasons behind server errors are given below:
That's just a small sample of the problems we could face. So, how do we deal with such a situation? If our application is running in production mode and an exception occurs, Flask will show us a very plain page and log the exception to the logger by default.
In the Flask application, when an error occurs, an HTTP status code will be returned. If the HTTP status code is between 400-499, that means the error occurs on the client-side data request. On the other hand, if the HTTP status code is between 500-599, then it means the error occurs on the server-side application.
When an error occurs with an HTTP status code, we can show custom error pages to the user with the help of error handlers. It can return responses when a certain type of error is occurred, which is similar to a function view that returns a response when the request URL is similar. It passes the object to handle the error, in most cases, it is an HTTPException.
Another thing to note is that the response's HTTP status code is not set to the error handler's code. When returning a response from the error handler, we must make sure to include that.
To deploy the python flask app on Heroku, follow the procedures outlined below:
Create a virtual environment with pipenv and install Flask and Gunicorn by running the command - $ pipenv install
Create a “Procfile” and write the following code - $ touch Procfile flask gunicorn
Create “runtime.txt” and write the following code - $ touch runtime.txt
Create a folder named “app” and enter the folder - $ mkdir app, $ cd app
Create a python file, “main.py” and enter the sample code - $ touch main.py
Get back to the previous directory “eflask”.Create a file“wsgi.py” and insert the following code - $ cd ../ , $ touch wsgi.py
Run the virtual environment - $ pipenv shell
Initialize an empty repo, add the files in the repo and commit all the changes - $ git init, $ git add
$ git commit -m "Initial Commit"
Login to heroku CLI using - heroku login
Now, Create a unique name for your Web app - $ heroku create eflask-app
Push your code from local to the heroku remote
$ git push heroku main
This question is a regular feature in interview questions on Flask, be ready to tackle it.
Flask makes it simple to manage uploaded files. Just remember to include the enctype="multipart/form-data" tag in your HTML form, or the browser will refuse to send your files. Uploaded files are kept in memory or on the filesystem in a temporary place. You may get to those files by looking at the request object's files attribute. Each file that is uploaded is saved in that dictionary. It has the same behavior as a typical Python file object, but it additionally provides a save() method that allows you to save the file to the server's filesystem. Here's a simple example to demonstrate how it works:
from flask import request[Text Wrapping Break][Text Wrapping Break]@app.route('/upload', methods=['GET', 'POST'])[Text Wrapping Break]def upload_file():[Text Wrapping Break] if request.method == 'POST':[Text Wrapping Break] f = request.files['the_file'][Text Wrapping Break] f.save('/var/www/uploads/uploaded_file.txt')The filename attribute can be used to determine how the file was named on the client before it was uploaded to your application. However, keep in mind that its value might be faked, so don't put your faith in it. If you wish to utilize the client's filename to store the file on the server, you can use the secure filename() function that Werkzeug provides:
from werkzeug.utils import secure_filename[Text Wrapping Break][Text Wrapping Break]@app.route('/upload', methods=['GET', 'POST'])[Text Wrapping Break]def upload_file():[Text Wrapping Break] if request.method == 'POST':[Text Wrapping Break] file = request.files['the_file'][Text Wrapping Break] file.save(f"/var/www/uploads/{secure_filename(file.filename)}") Expect to come across this popular question in interview questions on Flask.
You can find yourself in a position where you're dealing with data that should be correct but isn't. For example, you might have some client-side code that sends a faulty HTTP request to the server. This could be due to tampering with the data by a user or a bug in the client code. In most cases, responding with 400 Bad Request is sufficient, but this isn't always the case, and the code must continue to function.
You might still wish to note that something unusual occurred. Loggers come in handy in this situation. With Flask 0.3, you can utilize a logger that has been preconfigured for you.
The following are some examples of log calls:
app.logger.debug('A value for debugging')[Text Wrapping Break]app.logger.warning('A warning occurred (%d apples)', 42)[Text Wrapping Break]app.logger.error('An error occurred') To protect against injection attacks, any user-provided values rendered in the output must be enclosed when returning HTML (the default response type in Flask). This will be done automatically using HTML templates produced with Jinja.
The escape() function, which is seen below, can be used manually. Most examples remove it for brevity's sake, but you should constantly be conscious of how you're employing untrustworthy data.
from markupsafe import escape[Text Wrapping Break][Text Wrapping Break]@app.route("/<name>")[Text Wrapping Break]def hello(name):[Text Wrapping Break] return f"Hello, {escape(name)}!"If a user enters the name <script>alert("bad")</script>, it is rendered as text rather than running the script in the user's browser due to escaping.
We use the url_for() function to create a URL for a given function. It takes the function's name as the first parameter, as well as any number of keyword arguments, each of which corresponds to a variable component of the URL rule. As query parameters, unknown variable bits are appended to the URL.
Blueprints: A Blueprint is a method of organizing a collection of related views and other code. Instead of registering views and other code with an application directly, they are registered with a blueprint. When the blueprint is available in the factory function, it is then registered with the application. Flask will have two blueprints, one for authentication and the other for blog postings. Each blueprint's code will be kept in its own module.
Views: The code you write to reply to queries to your application is known as a view function. Flask matches the incoming request URL to the view that should handle it using patterns. Flask converts the data returned by the view into an outgoing response. Flask may also generate a URL for a view depending on its name and arguments in the other direction.
Autoescaping is the concept of having special characters automatically escape for you. &, >, <, ", and ' are special characters in the context of HTML (or XML, and thus XHTML). If you want to use these characters in the text, you must replace them with so-called "entities" because they have special meanings in documents on their own. Not doing so would not only frustrate users by preventing them from using certain characters in the text, but it might also lead to security issues. (For further information, see Cross-Site Scripting (XSS)).
However, you may need to disable autoescaping in templates on occasion. This is true if you want to inject HTML into sites explicitly, such as when they come from a system that generates secure HTML, such as a markdown to HTML converter.
There are three options for doing so:
You can use the {% autoescape %} block to disable the autoescape system in templates:[Text Wrapping Break]
{% autoescape false %}[Text Wrapping Break] <p>autoescaping is disabled here[Text Wrapping Break] <p>{{ will_not_be_escaped }}[Text Wrapping Break]{% endautoescape %}Please be very careful about the variables you use in this block whenever you do this.
Signals allow you to decouple apps by sending notifications when activities in the core framework or other Flask extensions occur. In a nutshell, signals allow particular senders to alert subscribers to an event.
Flask comes with a few signals, and other extensions may add more. Keep in mind that signals are meant to alert subscribers and should not be used to urge them to change their data. You'll notice that several signals appear to accomplish the same thing as some of the built-in decorators (for example, request started looks a lot like before request()). There are, however, variances in how they operate. The before request() handler, for example, is called in a certain order and can cancel a request by returning a response early. All signal handlers, on the other hand, run in an indeterminate order and do not affect any data.
Signals have a significant advantage over handlers in that you can safely subscribe to them for a fraction of a second. These temporary subscriptions are useful for things like unit testing. If you want to know which templates were rendered as part of a request, you can use signals to accomplish so.
Creating Signals: You can use the blinker library directly if you wish to use signals in your own application. Named signals in a custom Namespace are the most prevalent use case. Most of the time, this is what is suggested:
from blinker import Namespace[Text Wrapping Break]my_signals = Namespace()
You can now generate new signals such as this:
model_saved = my_signals.signal('model-saved')The signal's name makes it stand out and makes debugging easier. The name attribute gives you access to the signal's name.
A common question in Flask interview questions, don't miss this one.
It makes little sense to decorate the view class itself because it is not the view function that is introduced to the routing system. Instead, you'll have to hand-decorate the as_view() return value:
def user_required(f):[Text Wrapping Break] """Checks whether user is logged in or raises error 401."""[Text Wrapping Break] def decorator(*args, **kwargs):[Text Wrapping Break] if not g.user:[Text Wrapping Break] abort(401)[Text Wrapping Break] return f(*args, **kwargs)[Text Wrapping Break] return decorator[Text Wrapping Break][Text Wrapping Break]view = user_required(UserAPI.as_view('users'))[Text Wrapping Break]app.add_url_rule('/users/', view_func=view)Starting with Flask 0.8, you can also specify a list of decorators to use in the class declaration:
class UserAPI(MethodView):[Text Wrapping Break] decorators = [user_required]
Keep in mind that you can't use conventional view decorators on the individual methods of the view because of the implicit self from the caller's perspective.
During a request, CLI command, or other activity, the application context keeps track of application-level data. The current app and g proxies are used instead of passing the application around to each function.
This is similar to The Request Context. The Request Context, which keeps track of request-level data during a request, is comparable to this. When a request context is pushed, it is accompanied by an application context.
Purpose of Application Context: Aspects of the Flask application object, such as config, can be accessed via views and CLI commands. Importing the app instance into your project's modules, on the other hand, is prone to circular import difficulties. There will be no app instance to import when using the app factory pattern or developing reusable blueprints or extensions.
The application context in Flask overcomes this problem. Instead of referring to an app directly, you use the current_app proxy, which points to the application that is now handling the action.
When handling a request, Flask automatically pushes an application context. current_app will be accessible to view functions, error handlers, and other functions that run during a request.
Application Context Lifetime: As needed, the application context is generated and removed. A Flask application pushes an application context and a request context when it starts handling a request. When the request is completed, the request context is displayed, followed by the application context. An application context usually lasts the same amount of time as a request.
For creating application components and enabling common patterns within and between applications, Flask employs the concept of blueprints. Blueprints can help huge applications run more smoothly by providing a central location for Flask extensions to register activities on them. A Blueprint object is comparable to a Flask application object in functionality, but it is not one. It's more of a template on how to build or enhance an application.
Blueprints in Flask are designed for the following scenarios:
This is an example of a very basic blueprint. In this scenario, we'd like to create a blueprint that renders static templates simply:
from flask import Blueprint, render_template, abort[Text Wrapping Break]from jinja2 import TemplateNotFound[Text Wrapping Break][Text Wrapping Break]simple_page = Blueprint('simple_page', __name__,[Text Wrapping Break] template_folder='templates')[Text Wrapping Break][Text Wrapping Break]@simple_page.route('/', defaults={'page': 'index'})[Text Wrapping Break]@simple_page.route('/<page>')[Text Wrapping Break]def show(page):[Text Wrapping Break] try:[Text Wrapping Break] return render_template(f'pages/{page}.html')[Text Wrapping Break] except TemplateNotFound:[Text Wrapping Break] abort(404)When you use the @simple_page.route decorator to bind a function, the blueprint records your intent to have the function show up on the app when it's later registered. In addition, the endpoint of the method will be prefixed with the name of the blueprint that was sent to the Blueprint constructor (in this case, simple_page). The name of the blueprint does not change the URL, simply the endpoint.
There are a few of really good ways to improve the experience if you're already utilizing packages and blueprints for your application (Modular Applications with Blueprints). When the blueprint is imported, a common pattern is to create the application object. You can make additional copies of this app later if you move the creation of this object into a function.
So, why would you want to do something like this?
So, how would you go about putting that into practice? Well, the idea is to set up the application in a function which we call Application Factories
def create_app(config_filename):[Text Wrapping Break] app = Flask(__name__)[Text Wrapping Break] app.config.from_pyfile(config_filename)[Text Wrapping Break][Text Wrapping Break] from yourapplication.model import db[Text Wrapping Break] db.init_app(app)[Text Wrapping Break][Text Wrapping Break] from yourapplication.views.admin import admin[Text Wrapping Break] from yourapplication.views.frontend import frontend[Text Wrapping Break] app.register_blueprint(admin)[Text Wrapping Break] app.register_blueprint(frontend)[Text Wrapping Break][Text Wrapping Break] return app
The disadvantage is that you can't use the application object in blueprints when they're being imported. However, you can utilize it within a request. With the config, how do you gain access to the application? Make use of current_app:\
from flask import current_app, Blueprint, render_template[Text Wrapping Break]admin = Blueprint('admin', __name__, url_prefix='/admin')[Text Wrapping Break][Text Wrapping Break]@admin.route('/')[Text Wrapping Break]def index():[Text Wrapping Break] return render_template(current_app.config['INDEX_TEMPLATE']) On the WSGI level, application dispatching is the process of joining numerous Flask apps. You can mix and match any WSGI application, not only Flask. If you like, you can run a Django and a Flask application in the same interpreter at the same time. This is only useful if you know how the programs function within.
The main distinction between this and Large Applications as Packages is that you're running the same or different Flask applications that are completely separate from one another. They are dispatched on the WSGI level and run distinct configurations.
Each technique and example below produces an application object that may be run on any WSGI server. See Deployment Options for production options. Werkzeug provides a server for development via werkzeug.serving.run_simple():
from werkzeug.serving import run_simple[Text Wrapping Break]run_simple('localhost', 5000, application, use_reloader=True)It's worth noting that run simply isn't meant to be used in production. Make use of a production-ready WSGI server. See Deployment Options for more information.
Debugging must be enabled on both the application and the simple server in order to use the interactive debugger. The "hello world" example with debugging and run_simple is as follows:
from flask import Flask[Text Wrapping Break]from werkzeug.serving import run_simple[Text Wrapping Break][Text Wrapping Break]app = Flask(__name__)[Text Wrapping Break]app.debug = True[Text Wrapping Break][Text Wrapping Break]@app.route('/')[Text Wrapping Break]def hello_world():[Text Wrapping Break] return 'Hello World!'[Text Wrapping Break][Text Wrapping Break]if __name__ == '__main__':[Text Wrapping Break] run_simple('localhost', 5000, app,[Text Wrapping Break] use_reloader=True, use_debugger=True, use_evalex=True) URL processors are a new feature in Flask 0.7. The notion is that you may have a collection of resources with similar components in the URL that you don't always want to supply explicitly. For example, you might have a bunch of URLs with language code in them, but you don't want to have to deal with it in each and every function.
When used in conjunction with blueprints, URL processors are extremely useful. We'll deal with both application-specific URL processors and blueprint specifics here.
Internationalized Blueprint URLs: It's simple to prefix all URLs with a common string using blueprints, and it's trivial to do so for every function. Furthermore, blueprints can contain per-blueprint URL processors, which takes a lot of complexity from the url_defaults() function by eliminating the need to check if the URL is truly interested in the 'lang_code' parameter:
from flask import Blueprint, g[Text Wrapping Break][Text Wrapping Break]bp = Blueprint('frontend', __name__, url_prefix='/<lang_code>')[Text Wrapping Break][Text Wrapping Break]@bp.url_defaults[Text Wrapping Break]def add_language_code(endpoint, values):[Text Wrapping Break] values.setdefault('lang_code', g.lang_code)[Text Wrapping Break][Text Wrapping Break]@bp.url_value_preprocessor[Text Wrapping Break]def pull_lang_code(endpoint, values):[Text Wrapping Break] g.lang_code = values.pop('lang_code')[Text Wrapping Break][Text Wrapping Break]@bp.route('/')[Text Wrapping Break]def index():[Text Wrapping Break] ...[Text Wrapping Break][Text Wrapping Break]@bp.route('/about')[Text Wrapping Break]def about():[Text Wrapping Break] ... This is a frequently asked question in interview questions on Flask for experienced.
If Flask is installed with the async extra, routes, error handlers, before request, after request, and teardown methods can all be coroutine functions (pip install flask[async]). Where ContextVars are used, Python 3.7 or above is required. ContextVar is a variable that can be used. Async def and await can now be used to define views.
@app.route("/get-data")[Text Wrapping Break]async def get_data():[Text Wrapping Break] data = await async_db_query(...)[Text Wrapping Break] return jsonify(data)Coroutine-based handlers are also supported by pluggable class-based views. This is true for views that inherit from the flask.views' dispatch_request() method. All HTTP method handlers in views that inherit from flask.views, as well as the View class. MethodView is a class that represents a method.
The execution of async functions necessitates the use of an event loop. As a WSGI application, Flask employs a single worker to manage a single request/response cycle. When an async view receives a request, Flask creates an event loop in a thread, runs the view function there, and then returns the result.
Even for async views, each request ties up one worker. On the plus side, you may use async code within a view to perform numerous concurrent database queries, HTTP connections to an external API, and so on. However, the maximum number of requests your application can manage at any given time will not change.
Async code isn't always faster than sync code. When doing concurrent IO-bound work, async is useful, but it is unlikely to improve CPU-bound operations. Traditional Flask views will continue to be appropriate for the majority of use cases, but Flask's async support allows you to write and use code that wasn't previously possible.
When to use Quart instead: Because of the way Flask's async support is designed, it is slower than async-first frameworks. It makes sense to investigate Quart if your codebase is primarily async. Quart is a Flask reimplementation based on the ASGI standard rather than the WSGI standard. This enables it to manage a large number of concurrent requests, long-running requests, and WebSockets without the need for many worker processes or threads.
Many of the benefits of async request handling can also be obtained by running Flask with Gevent or Eventlet. To do this, these libraries tweak low-level Python methods, whereas async/ await and ASGI make use of regular, current Python features. Understanding the individual needs is the most important factor in deciding whether to utilize Flask, Quart or something else.
Setuptools is a Python extension library for distributing Python libraries and extensions. It enhances distutils, a rudimentary module installation system included with Python, to include a number of more complicated operations that make it easier to distribute larger applications:
Setuptools or distutils are used to distribute Flask and all of the libraries available on PyPI. If you have already installed Flask, then you also have setuptools available on your system because Flask is dependable on setuptools. A Flask application's basic setup.py file looks like this:
from setuptools import setup[Text Wrapping Break][Text Wrapping Break]setup([Text Wrapping Break] name='Your Application',[Text Wrapping Break] version='1.0',[Text Wrapping Break] long_description=__doc__,[Text Wrapping Break] packages=['yourapplication'],[Text Wrapping Break] include_package_data=True,[Text Wrapping Break] zip_safe=False,[Text Wrapping Break] install_requires=['Flask'][Text Wrapping Break])
Please keep in mind that you must explicitly list subpackages. You can use the find packages method to have setuptools hunt up the packages for you automatically:
from setuptools import setup, find_packages[Text Wrapping Break][Text Wrapping Break]setup([Text Wrapping Break] ...[Text Wrapping Break] packages=find_packages()[Text Wrapping Break])
Fabric is a Python program that works similarly to Makefiles but also allows you to run commands on a remote server. Flask applications may be easily deployed to other servers when used in conjunction with a well configured Python package (Large Applications as Packages) and a good configuration concept (Configuration Handling).
Before we get started, here's a quick rundown of what we need to be sure of:
Create a simple Fabfile: Fabric's execution is controlled by a fabfile. It's called fabfile.py, and it's run with the fab program. All of the functions in that file will be available as fab subcommands. They are run on a single or several hosts. These hosts can be specified on the command line or in the fabfile. We'll add them to the fabfile in this scenario.
This is a simple initial example that allows you to upload current source code to the server and install it into a virtual environment that already exists:
from fabric.api import *[Text Wrapping Break][Text Wrapping Break]# the user to use for the remote commands[Text Wrapping Break]env.user = 'appuser'[Text Wrapping Break]# the servers where the commands are executed[Text Wrapping Break]env.hosts = ['server1.example.com', 'server2.example.com'][Text Wrapping Break][Text Wrapping Break]def pack():[Text Wrapping Break] # build the package[Text Wrapping Break] local('python setup.py sdist --formats=gztar', capture=False)[Text Wrapping Break][Text Wrapping Break]def deploy():[Text Wrapping Break] # figure out the package name and version[Text Wrapping Break] dist = local('python setup.py --fullname', capture=True).strip()[Text Wrapping Break] filename = f'{dist}.tar.gz'[Text Wrapping Break][Text Wrapping Break] # upload the package to the temporary folder on the server[Text Wrapping Break] put(f'dist/{filename}', f'/tmp/{filename}')[Text Wrapping Break][Text Wrapping Break] # install the package in the application's virtualenv with pip[Text Wrapping Break] run(f'/var/www/yourapplication/env/bin/pip install /tmp/{filename}')[Text Wrapping Break][Text Wrapping Break] # remove the uploaded package[Text Wrapping Break] run(f'rm -r /tmp/{filename}')[Text Wrapping Break][Text Wrapping Break] # touch the .wsgi file to trigger a reload in mod_wsgi[Text Wrapping Break] run('touch /var/www/yourapplication.wsgi')So, how do you put that fabfile into action? The fab command is what you use. This command would be used to deploy the current version of the code to the remote server:
$ fab pack deploy
How to redirect a user to another endpoint? Explain how to handle errors for redirecting a user.
Use the redirect() function to send a user to another endpoint; use the abort() function to abort a request early with an error code:
from flask import abort, redirect, url_for[Text Wrapping Break][Text Wrapping Break]@app.route('/')[Text Wrapping Break]def index():[Text Wrapping Break] return redirect(url_for('login'))[Text Wrapping Break][Text Wrapping Break]@app.route('/login')[Text Wrapping Break]def login():[Text Wrapping Break] abort(401)[Text Wrapping Break] this_is_never_executed()Because a user will be diverted from the index to a page they cannot access (401 denotes access forbidden), this is a fairly worthless example, but it demonstrates how it works.
For each error code, a black and white error page is displayed by default. You may use the errorhandler() decorator to personalize the error page:
from flask import render_template[Text Wrapping Break][Text Wrapping Break]@app.errorhandler(404)[Text Wrapping Break]def page_not_found(error):[Text Wrapping Break] return render_template('page_not_found.html'), 404Take note of the 404 that appears following the render template() function. This tells Flask that the page's status code should be 404, which stands for "not found." By default, the value 200 is assumed, which means that everything went smoothly.
It's no surprise that this one pops up often in Flask interview questions for experienced.
Most error handlers will operate as expected in Modular Applications with Blueprints. There is a caveat, though, when it comes to handlers for 404 and 405 errors. These error handlers are only called when there is an appropriate raise statement or a call to abort in one of the blueprint's view functions; they are not called when there is invalid URL access, for example.
Because the blueprint does not own a certain URL space, the application instance has no means of knowing which blueprint error handler to apply if the URL is wrong. If you want to use alternative handling strategies for these errors based on URL prefixes, you can do so using the request proxy object at the application level.
from flask import jsonify, render_template[Text Wrapping Break][Text Wrapping Break]# at the application level[Text Wrapping Break]# not the blueprint level[Text Wrapping Break]@app.errorhandler(404)[Text Wrapping Break]def page_not_found(e):[Text Wrapping Break] # if a request is in our blog URL space[Text Wrapping Break] if request.path.startswith('/blog/'):[Text Wrapping Break] # we return a custom blog 404 page[Text Wrapping Break] return render_template("blog/404.html"), 404[Text Wrapping Break] else:[Text Wrapping Break] # otherwise we return our generic site-wide 404 page[Text Wrapping Break] return render_template("404.html"), 404[Text Wrapping Break][Text Wrapping Break]@app.errorhandler(405)[Text Wrapping Break]def method_not_allowed(e):[Text Wrapping Break] # if a request has the wrong method to our API[Text Wrapping Break] if request.path.startswith('/api/'):[Text Wrapping Break] # we return a json saying so[Text Wrapping Break] return jsonify(message="Method Not Allowed"), 405[Text Wrapping Break] else:[Text Wrapping Break] # otherwise we return a generic site-wide 405 page[Text Wrapping Break] return render_template("405.html"), 405 Flask began as a demonstration of how to create your own framework using well-known tools like Werkzeug (WSGI) and Jinja (templating), but as it grew in popularity, it became helpful to a broader audience. Don't just utilize Flask as you expand your codebase; learn it. Check out the source. Flask's code is written to be read, and its documentation is available for users with its internal APIs. Flask follows upstream libraries' defined APIs and describes its internal utilities so you can locate the hook points you need for your project.
Hook and Extend: The API documentation is full of overrides, hook points, and Signals. Custom classes can be provided for request and response objects, for example. Look at the APIs you're using and see what customizations are available right out of the box in a Flask release. Look for ways to rework your project into a collection of Flask extensions and utilities. If you can't discover what you're looking for among the many Extensions in the community, seek for patterns to develop your own.
Subclass: Many methods of the Flask class are intended for subclassing. Subclassing Flask (see the linked method instructions) and using that subclass anywhere you instantiate an application class allows you to rapidly add or alter behavior. This is a great way to use Application Factories. For an example, see Flask Subclassing.
Wrap with middleware: The Application Dispatching pattern explains how to use middleware in detail. To encapsulate your Flask instances and introduce repairs and updates at the layer between your Flask application and your HTTP server, you can use WSGI middleware. Werkzeug comes with a number of middlewares.
Fork: Fork Flask if none of the preceding options work. Werkzeug and Jinja2 contain the majority of Flask's code. The majority of the work is done by these libraries. Flask is simply the glue that holds them together. Every project has a moment where the underlying framework becomes a hindrance (due to assumptions the original developers had). This is understandable because if it weren't, the framework would be an extremely complex system from the start, resulting in a steep learning curve and a lot of user irritation.
For many online applications, code complexity is less of a concern than scaling for the expected number of users or data entries. Flask's scalability capabilities are restricted solely by your application code, the data store you choose to utilize, and the Python implementation and web server you're using.
Scaling well means, for example, that doubling the number of servers yields roughly double the performance. Scaling poorly means that adding a new server will not improve performance or will not even support a second server. In Flask, the context local proxies are the only limiting element in terms of scaling. They are dependent on context, which is defined in Flask as a thread, process, or greenlet. Flask will no longer be able to support global proxies if your server uses a concurrency model that isn't based on threads or greenlets. However, the majority of servers achieve concurrency by using threads, greenlets, or different processes, all of which are fully supported by the Werkzeug framework.
Though Flask is newer than other Python frameworks, it has a bright future ahead of it and is gaining popularity among Python web developers. Check out KnowledgeHut Flask certification training course if you want to learn more about the fundamentals of Flask. Flask's major purpose was to create a solid foundation for web applications of various needs and sophistication. After that, users are free to use whatever extensions they choose. Furthermore, one is free to create their own modules, and Flask is ideal for such applications.
Flask is an excellent prototyping framework that relies on two external libraries: the Jinja2 template engine and the Werkzeug WSGI toolkit. Flask is one of the most visually appealing and feature-rich microframeworks in Python. Flask is a relatively new framework with a strong community, an intuitive API, and first-class extensions. Flask offers all of the advantages of quick templates, robust WSGI features, strict unit testability at both the web application and library level, and substantial documentation. Our Python Flask interview questions and answers will help you prepare and ace any interview with flying colors. To learn and strengthen your fundamentals, join our basic web development course today.
Submitted questions and answers are subjecct to review and editing,and may or may not be selected for posting, at the sole discretion of Knowledgehut.
Get a 1:1 Mentorship call with our Career Advisor
By tapping submit, you agree to KnowledgeHut Privacy Policy and Terms & Conditions