Flask против Django: выберите веб-фреймворк Python

Flask или Django?

По данным исследования 2018 Python Developers Survey, Flask и Django, безусловно, являются самыми популярными веб-фреймворками для разработчиков на Python. Вы вряд ли ошибетесь с выбором любого из этих фреймворков, если решаете, какой из них использовать для нового веб-приложения.

Хотя вы сами решаете, какой из них лучше всего подходит для того, чего вы пытаетесь достичь, есть несколько основных различий, о которых вы должны знать при принятии решения. Независимо от того, какой фреймворк вы в итоге используете, оба они очень хорошо документированы и широко используются, поэтому у них достаточно активные и поддерживающие сообщества.

Итак, без лишних слов, давайте рассмотрим, что предлагает каждый фреймворк, и выделим некоторые их различия и сходства.

TL;DR Различия Flask vs Django

Flask и Django - это зрелые, расширяемые веб-фреймворки, которые, в своей основе, предлагают схожую функциональность в обработке запросов и обслуживании документов, но отличаются по сфере ответственности.

Большая часть различий между двумя фреймворками обусловлена этим разным подходом, хотя некоторые из них также обусловлены разным дизайном ядра.

Вот краткий список ключевых различий, которые могут повлиять на ваше решение:

  • Объект запроса - Flask использует потоки-локализаторы, в то время как Django передает запрос туда, где он нужен.
  • Формы - Django поставляется со встроенными формами, которые интегрируются с ORM и администратором сайта. Flask не имеет поддержки форм по умолчанию, но вы можете использовать WTForms, чтобы заполнить этот пробел.
  • База данных - Django поставляется с Django ORM и системой миграции, которая хочет управлять вашей базой данных. Flask не делает никаких предположений о базе данных, но есть инструменты, такие как SQLAlchemy, которые обеспечивают аналогичную функциональность (возможно, даже больше).
  • Аутентификация и разрешения - Django поставляется с приложением аутентификации, которое предоставляет реализацию по умолчанию для управления пользователями и разрешениями. Flask предоставляет безопасные cookies как инструмент для вашей собственной реализации.
  • Admin Site - Django поставляется с полностью интегрированным интерфейсом администратора для управления данными приложения. Flask не поставляется ни с чем подобным, но Flask-Admin - популярное расширение, которое можно использовать для создания аналогичного инструмента администрирования.

Что такое Django?

На сайте Django говорится, что "Django облегчает создание лучших веб-приложений быстрее и с меньшим количеством кода", и называет Django "веб-фреймворком для перфекционистов со сроками". Действительно, Django - это зрелый фреймворк, который (по умолчанию) самостоятельно принимает многие решения, чтобы пользователь имел ту готовую утилиту, которая необходима в типичном веб-приложении.

Если вы довольны большинством этих решений и настройками по умолчанию, которые предоставляет Django, вы можете получить относительно сложное веб-приложение за довольно короткое время.

Некоторые компании, которые используют Django:

  • Instagram
  • Pinterest
  • Udemy
  • Coursera
  • Zapier

Что такое Flask?

На сайте Flask Flask описывается как "микрофреймворк для Python, основанный на Werkzeug, Jinja 2 и добрых намерениях", а слоган гласит: "Веб-разработка, по капле за раз". Это еще раз дает вам хорошее представление о том, какое место Flask пытается заполнить в переполненном мире веб-фреймворков Python.

В частности, Flask стремится служить минимальным фреймворком, который хорошо обрабатывает несколько вещей, но затем оставляет большую часть решений о том, как вы хотите построить свое веб-приложение, на ваше усмотрение - либо через собственные реализации, либо через любое количество сторонних расширений.

Компании, которые используют Flask:

  • Netflix
  • Lyft
  • Reddit
  • Zillow
  • MailGun

Как проявляют себя эти различные подходы?

Чтобы лучше понять сходства и различия между Flask и Django, давайте рассмотрим, что они предлагают в рамках некоторых высокоуровневых функций, которые можно найти в типичных веб-приложениях.

Среда разработки

Сервер разработки

Как Django, так и Flask поставляются в комплекте с серверами разработки, что позволяет легко и удобно быстро приступить к созданию веб-приложения. Они оснащены функциями, которые вы ожидаете от зрелого веб-фреймворка, такими как способность обрабатывать запросы, обслуживать статические файлы (для разработки) и определять, когда ваш код меняется, чтобы автоматически перезапустить и сделать ваши изменения доступными.

Утилиты командной строки

Django предоставляет утилиту командной строки, которая поставляется с набором команд управления. Одна из них запускает сервер разработки, а другие используются для управления статическими файлами и для работы с миграциями. Сторонние приложения могут расширить возможности утилиты командной строки, предлагая свои собственные команды управления, и может быть полезно (и легко) добавить несколько своих собственных. Flask также имеет встроенную утилиту командной строки, использующую click, которая является зрелым и надежным набором инструментов интерфейса командной строки. Как и в Django, можно добавлять свои собственные команды, а расширения Flask также могут вносить свои собственные.

Тестирование

Оба фреймворка предлагают инструменты, основанные на встроенном фреймворке python unittest, чтобы облегчить тестирование веб-приложений. Каждый из них имеет тестовый клиент, который позволяет легко отправлять тестовые запросы к конечным точкам и проверять ответ для подтверждения правильного поведения программным путем. Поскольку и Flask, и Django используют встроенный фреймворк python unittest, вы можете заменить тестовые клиенты по умолчанию и настроить тесты по своему вкусу.

Обработка запросов

Маршруты и виды

И Flask, и Django позволяют обрабатывать запросы, определяя представления в виде функции или класса, а затем сопоставляя маршруты (пути URL) с этими представлениями.

По умолчанию Django организует логику обработки запросов (представления) отдельно от определения маршрутизации. Для каждого приложения вы обычно определяете свои "шаблоны url" в одном файле, который сопоставляет каждый шаблон с представлением для обработки запросов, соответствующих этому шаблону url.

Преимуществом этого метода является наличие одного места, в котором вы можете видеть, куда должен быть направлен запрос. Хотя вы можете сделать то же самое во Flask, чаще всего маршруты объявляются в том же месте, что и представление, либо с помощью декоратора, либо путем явной регистрации маршрута в объекте приложения (или чертеже, если вы их используете).

Следующие примеры маршрутизации пути "home/" иллюстрируют разницу.

В Django:

from django.urls import path

from .views import HomeView

urlpatterns = [
    path('home/', HomeView.as_view(), name='home'),
]

В колбе:

from flask import Flask, render_template

app = Flask(__name__)

@app.route('/home/')
def home_view():
    """
    Definition of Home View
    """
    return render_template("home.html")

Когда дело доходит до представлений на основе классов, Django начинает отличаться от других, предлагая большое разнообразие дополнительных базовых классов, которые предлагают модифицируемые базовые реализации для некоторых общих паттернов, встречающихся в веб-приложениях. Например, класс FormView объединяет логику HTTP GET и POST для отображения и обработки вводимых данных для Django Form.

Существует ряд таких общих представлений, которые позволяют вам построить многое быстро и с минимальным кодом, если то, что вы строите, подходит под форму.

Объект запроса

И во Flask, и в Django есть "объект запроса", который хранит данные о запросе, но то, как этот объект предоставляется фреймворком, довольно сильно отличается.

В Django объект запроса передается представлению в качестве аргумента и должен передаваться каждый раз, когда он необходим. Большим преимуществом этой конструкции является то, что

Flask, с другой стороны, использует совершенно иной подход и использует локальную переменную потока для хранения запроса. Это означает, что если вы хотите получить доступ к объекту запроса, вам просто нужно импортировать объект запроса из flask и сослаться на него в своем коде. Преимущество такого подхода в том, что вам не нужно передавать запрос по кругу. Если он вам нужен - вы просто получаете к нему доступ. Довольно большой недостаток заключается в том, что если вы не будете осторожны, то можете запутаться, когда вы находитесь в контексте запроса, а когда нет. Это приводит к тому, что многие новые пользователи Flask получают ошибки об отсутствии контекста запроса при попытке запустить свой код.

Шаблоны

Для своего шаблонизатора Flask использует существующий инструмент под названием Jinja2. Это очень популярный шаблонизатор с множеством функций, которые позволяют вам создавать многие статические html-части вашего сайта без необходимости выполнять много повторяющейся работы.

Django имеет свой собственный движок шаблонов, который имеет очень похожий синтаксис и схожий набор функций с Jinja 2. На самом деле, если вы предпочитаете использовать только Jinja2, его достаточно просто установить в качестве движка шаблонов.

Описание различий между Jinja2 и шаблонизатором Django можно найти здесь, но чтобы получить представление о синтаксисе, смотрите следующее

Jinja2:

{% for item in obj.get_items() %}
  {{item}}
{% endfor %}

Django:

{% for item in obj.get_items %}
  {{item}}
{% endfor %}

Статические файлы

Следить за статическими файлами и знать, как ссылаться на них в коде и шаблонах таким образом, чтобы они поддерживали различные среды, может быть несколько затруднительно. Для решения этой проблемы оба фреймворка предлагают утилиты для ссылок на статические файлы, чтобы на основе вашей конфигурации урлы, ссылающиеся на ваши статические файлы, были правильно сгенерированы для данного окружения.

Дополнительно Django предоставляет команду управления для сбора статических файлов из ваших различных приложений и размещения их там, где указано в вашей конфигурации. Это очень удобно, когда нужно развернуть ваше приложение в производственной среде.

Вот пример того, как просто ссылаться на статические файлы в шаблонах для каждого фреймворка.

Django:

{% load static %}
<link type="text/css" href="{% static "style.css" %}">

Фляга:

<link type="text/css" href="{{ url_for('static', filename='style.css') }}">

Расширяемость

Flask, по своей природе, был создан для расширения. Как часть его дизайна

Хотя Django принимает больше решений за вас, он также не поддерживает все возможные варианты и имеет подключаемую структуру приложений, которая позволяет многое настраивать и расширять. В конечном счете, оба фреймворка имеют очень богатый выбор сторонних расширений, так что есть шанс, что если вам нужно решение какой-либо, казалось бы, распространенной проблемы, вы с большой вероятностью найдете уже готовое решение.

Forms

С помощью декларативного синтаксиса Django предлагает простой способ определения объектов форм, которые затем позволяют единообразно отображать и обрабатывать данные. Формы отображаются с помощью встроенных шаблонов, которые можно переопределять для настройки внешнего вида.

Формы в Django помогают вам обрабатывать валидацию данных и механизмы безопасности, такие как защита CSRF, "из коробки", чтобы вам не нужно было об этом думать. В Django есть специальный класс форм (ModelForm), который интегрируется с Django ORM Models, чтобы облегчить быстрое определение форм из ваших моделей данных.

Flask, однако, не предоставляет никакой обработки форм из коробки, но довольно просто использовать такой пакет, как WTForms, который обеспечивает функциональность, подобную той, которую предоставляют формы Django.

Поддержка баз данных

Объектно-реляционное отображение, миграции

Django поставляется в комплекте с Django ORM (Object Relational Mapping). Это, вероятно, одно из самых спорных решений, которые принимает Django. Некоторые люди любят Django ORM за его простоту, а некоторые ненавидят его, ссылаясь на недостатки и его желание управлять базой данных за вас. Однако несомненно, что он позволяет очень быстро начать работу, и в его простоте кроется большая сила.

ORM поставляется в комплекте с инструментом для автоматической генерации и управления миграциями баз данных. Используя предоставленные команды управления, вы можете быстро перемещаться, изменяя определения Django Model, и в значительной степени миграции базы данных будут обработаны за вас: существует ряд ситуаций, в которых автогенерируемые миграции нуждаются в помощи.

ОРМ Django очень своеобразен и имеет некоторые определенные ограничения, но его можно настраивать, расширять, и в конечном итоге вы можете прибегнуть к необработанному SQL, если у вас возникнет необходимость преодолеть эти ограничения.

Flask специально избегает включения всего, что связано с управлением базами данных. Документация Flask правильно указывает, что некоторые веб-приложения вообще не будут обращаться к базе данных.

Для приложений, которые это делают, существует так много вариантов баз данных на выбор, которые могут подойти для вашего случая использования, что лучше оставить логику на усмотрение других (не веб-фреймворка).

Если вы хотите использовать ORM с Flask, есть несколько вариантов - но если вы используете реляционную базу данных, наиболее популярным вариантом будет SQLAlchemy, который намного больше, чем ORM, и обеспечивает отличное решение.

Аутентификация и разрешения

Django поставляется с приложением аутентификации, которое вертикально интегрируется с остальной системой для обеспечения модели пользователя, системы разрешений и поддержки сессий. В этом приложении есть ряд решений, с которыми вы можете согласиться или не согласиться, и вы вольны либо изменить их под свои нужды, либо обойти их полностью. Например, довольно распространено переопределение модели пользователя по умолчанию и использование модели, в которой в качестве имени пользователя используется электронная почта

Из коробки Flask не предоставляет решения для аутентификации. Возможно, у вашего веб-приложения даже нет необходимости в аутентифицированных пользователях. Как обычно, если вы ищете способ добавить аутентификацию пользователей во Flask, существуют расширения, которые помогут вам облегчить жизнь. Единственный строительный блок, который предоставляет Flask, - это безопасные куки, которые удобно использовать для реализации схемы аутентификации.

Админ сайта

Django поставляется в комплекте с админкой, которая позволяет быстро создать внутренний инструмент для управления данными из ваших моделей данных. Когда вы пытаетесь быстро запустить веб-приложение, Django Admin - это действительно простой способ предоставить простой интерфейс для управления данными приложения. Вы можете далеко продвинуться, используя всего несколько строк кода, а по мере развития вашего приложения вы можете настраивать внешний вид и функциональность администратора по своему усмотрению.

Flask не поставляется с каким-либо интерфейсом администратора, но (здесь нет ничего удивительного) расширение Flask-Admin предоставляет нечто похожее на то, что предоставляет Django - хотя его немного сложнее настроить, поскольку вам придется интегрировать его с любой схемой аутентификации, которую вы реализуете.

Безопасность

Оба фреймворка делают все возможное, чтобы обеспечить вам надежную защиту безопасности. Документация Flask предупреждает разработчиков о необходимости быть осторожными, поскольку независимо от того, что предоставляет фреймворк, если разработчики не будут осторожны в применении инструментов, могут возникнуть уязвимости безопасности.

С этой точки зрения, поскольку Django делает больше за вас, он также решает больше вопросов безопасности. Однако, в конечном счете, все зависит от разработчика, который должен быть осторожен, читать всю документацию и принимать взвешенные решения.

Заключение

Хотя многие выбирают один фреймворк вместо другого по своему вкусу, в конце концов, вы легко привыкаете к этим различиям. Если вам приходится выбирать между этими двумя фреймворками, посмотрите на свои потребности. Если ваше веб-приложение будет нуждаться в аутентифицированных пользователях, в Django есть много хороших решений, которые помогут ускорить вашу разработку, и их стоит изучить. Если вы довольно категорично относитесь к своей базе данных, не хотите, чтобы она управлялась веб-фреймворком, или если у вас вообще нет базы данных, то Django, вероятно, не имеет для вас особого смысла. В конечном счете, вы можете сделать проект Flask очень похожим на проект Django, и вы можете убрать Django, чтобы он больше походил на проект Flask, но это не всегда хорошо потраченное время. Поэтому лучше заранее ознакомиться с возможностями каждого из них. Если вам нужно все, что предлагает Django, и вы не против того, чтобы Django управлял вашей базой данных, то это действительно сильный вариант. Трудно превзойти удобство и скорость, с которой вы можете создавать свои веб-приложения. Если вам не нужно то, что предлагает Django, или вам не нравится выбор, который он делает, тогда имеет смысл начать с Flask и создавать свои веб-приложения так, как вы считаете нужным.

Вернуться на верх