Прим. перев.: Эта статья рассчитана в основном на тех кто только выбирает фреймворк для веб-разработки. Опытные разработчики на Django вряд ли узнают что-то новое.



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


Фреймворк поможет разработать CRUD приложение под ключ. С Django не придется изобретать велосипед. Он работает из коробки и позволит сосредоточиться на бизнес-логике и продуктах для обычных людей.


Плюсы Джанго


Принцип «Всё включено» («Batteries included»)


Фраза «всё включено» означает, что большинство инструментов для создания приложения — часть фреймворка, а не поставляются в виде отдельных библиотек.


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


  • ORM
  • Миграции базы данных
  • Аутентификация пользователя
  • Панель администратора
  • Формы

Стандартизированная структура


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


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


Приложения Django


Приложения в Django позволяют разделить проект на несколько частей. Приложения устанавливаются путём добавления в settings.INSTALLED_APPS. Этот подход позволяет легко интегрировать готовые решения.


Сотни универсальных модулей и приложений очень сильно ускорят разработку. Взгляните на их список на сайте djangopackages.org.


Безопасный по умолчанию


Django безопасен из коробки и включает механизмы предотвращения распространенных атак вроде SQL-инъекций (XSS) и подделки межсайтовых запросов (CSRF). Подробнее об этом можно почитать в официальном руководстве по безопасности.


REST Framework для создания API


Django REST Framework, который часто сокращают до «DRF», является библиотекой для построения API. Он имеет модульную и настраиваемую архитектуру, которая хорошо работает для создания как простых, так и сложных API.


В DRF политики аутентификации и разрешений доступны из коробки. Он поставляется с базовыми классами для CRUD операций и встроенной утилитой для тестирования разрабатываемого API.


GraphQL фреймворк для создания API


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


Graphene-Django позволит легко добавить соответствующую функциональность в ваш проект. Модели, формы, аутентификация, политики разрешений и другие функциональные возможности Django можно использовать для создания GraphQL API. Библиотека так же поставляется с утилитой для тестирования результата.


Недостатки Джанго


Django ORM


Django ORM сегодня значительно уступает последней SQLAlchemy.


Django ORM основан на шаблоне Active Record, который хуже, чем шаблон Unit of Work, используемый в SQLAlchemy. На практике это выражается в том, что в Django модели могут «сохранять» себя по желанию, а транзакции отключены по умолчанию. Подробнее об этом можно почитать в статье «Вещи, которые мне не нравятся в Django».


Django развивается медленно


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


В итоге: должен ли я выбрать Django?


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


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


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

Комментарии (15)


  1. ZaEzzz
    25.10.2019 12:12

    Что-то как-то однобоко и мало.
    А где же отсутствие асинхронности и прочие вещи?


    1. eumorozov
      25.10.2019 12:25

      Асинхронность должна быть в Django 3.0. Но да, информации маловато.


      1. ZaEzzz
        25.10.2019 12:39

        Ну она вроде как не должна быть, а будет. Но блин, ASGI и все равно все блокируется на той же ORM.
        Наверное в четвертую версию завезут что-то уже достойное, но это не точно.


        1. eumorozov
          25.10.2019 12:41

          Потому и написал «должна быть», т.к. не знаю, допилят ли асинхронный ORM в третьей версии. Настолько пристально следить за ее разработкой не хватает времени.


          1. ZaEzzz
            25.10.2019 12:49

            Не, они объявили, что асинхронщины в ORM не будет к релизу и это будет unsafe в асинхронном контексте.


      1. rSedoy
        25.10.2019 14:10

        Можно сказать, что в 3.0 асинхронности не будет. Это версия начало большого пути по добавлению асинхронность в Django, подробней habr.com/ru/post/461493


  1. Maksclub
    25.10.2019 12:59

    Django ORM основан на шаблоне Active Record, который хуже, чем шаблон Unit of Work

    Технически все же AR паттерн противопоставляется паттерну Data Mapper, который собственно маппит данные на бизнес-модель, освобождая эту самую модель от логики бд.


  1. worldmind
    25.10.2019 15:58

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


  1. crlam0
    25.10.2019 17:19
    +1

    Django безопасен из коробки и включает механизмы предотвращения распространенных атак вроде SQL-инъекций (XSS) и подделки межсайтовых запросов (CSRF). Подробнее об этом можно почитать в официальном руководстве по безопасности.

    SQL инъекции и XSS (Cross Site Scripting) это совсем разные векторы атак, автор оригинала видимо сам не особо читал официальное руководство по безопасности, там они (SQL инъекции и XSS) в разных разделах.


  1. OnYourLips
    25.10.2019 22:47
    +1

    Django ORM сегодня значительно уступает последней SQLAlchemy.

    Она не просто уступает, а реализует антипаттерн Active Record, который сильно усложняет длительную разработку проекта.


    Более того, в Django крайне сильносвязанные компоненты, поэтому даже при замене Django ORM на SQLAlchemy перестанут работать другие компоненты, например админка.


  1. beduin01
    26.10.2019 07:31

    Джангу могут любить только те кто ничего другого не знает/пробовал.


    По факту она не упрощает, а усложняет разработку. Лет 15 назад она может и была полезна, но сейчас от нее больше проблем чем пользы.


    Для маленких проектов она слишком тяжеловесна, для больших от нее обычно только Rest берут


    1. eumorozov
      26.10.2019 13:41
      +1

      Джангу могут любить только те кто ничего другого не знает/пробовал.

      Другого чего, например?


      1. LireinCore
        26.10.2019 16:41
        +2

        PHP Symfony


      1. Concrete
        28.10.2019 15:30

        Pyramid


  1. stalkerg
    28.10.2019 18:03

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

    В корне с этим не согласен. Вначале может быть готовые батарейки и спасают но потом все все равно приходится переписывать и делать кастомные варианты и именно тут гибкость легких подходов дают свою пользу.
    Ну и честно говоря для большинства кейсов в python есть готовые "плагины" которые можно хоть с Tornado хоть с Sanic использовать без особых трудов.