.png)
Автор: Виктор Морщ, Developer/PHP support
Материалы статьи подготовлены в рамках внутренней программы менторства и обучения специалистов команды Evergreen.
Фреймворки Laravel и Django — это два больших “комбайна” для разработки веб-приложений. У них мощный функционал по части бэкенда, собственные системы роутинга, ORM-системы, админка, широкое комьюнити. У Laravel при этом еще есть куча сторонних сервисов для сборки фронта и библиотека приложений, которые постоянно развиваются и поддерживаются авторами. Давайте поговорим о некоторых возможностях этих программных платформ.
Последние пару лет на Laravel и Django приходится по 10-15% запросов на Stack Overflow, касающихся веб-фреймворков. На Github у Ларавел больше просмотров и больше звезд:
Источник: github.com
“Дерево” связанных технологий на Stack Overflow выглядит довольно интересно: Laravel находится в самом низу и близко к блоку фронтенд-технологий (React, Angular и т.д.), рядом с MySQL и Node.js. Django видим вверху схемы, через Python ведет связь в сторону Linux, Docker, Kubernetes, AWS и других. Эти связи строятся на базе поисковых запросов пользователей, и можно предположить, что аудитория Джанго и Ларавел не слишком пересекается. Но такая статистика не означает автоматически, что пользователи Laravel активно взаимодействуют с JS и фронтом, а те кто пишут на Django, с ними не соприкасаются. Ведь, например, для одностраничного приложения без разницы, что на бэкенде: Django, Laravel или что-то другое.
Источник: stackoverflow.com
Подходы к моделям в Laravel и Django отличаются. В Laravel модель — это некая “инструкция” как работать с таблицами в базе.
Видим, что у сущности Account есть связь belongsToMany с сущностью loyalty_action. Модели в Ларавел могут быть как простые, так и обширные и содержать скрытые поля, прослушивание событий. Структура здесь декларируется отдельными миграциями. Лежат модели в папке App.
В Django модель декларирует структуру базы данных: описываются поля, их характеристики, типы данных, ограничения по длине, задается человекочитаемое название. Преимущество Django — то, что информация касательно сущностей хранится в одном месте.
Здесь описываются поля и стандартные функции, которые помогают взаимодействовать с базой. Также информация с фрагмента кода выше используется при валидации запросов к методам API сущности Project. В структуре проекта также найдем папку migrations — миграции генерируются из моделей.
В Laravel модель фактически состоит только из функций, а сами поля не описываются.
Вам будет интересно: Low-Code и Zero-Code: как вы можете создавать кастомные приложения без программистов
ORM-система Laravel называется Eloquent ORM. Синтаксис у Eloquent ORM SQL-подобный:
Мы получаем экземпляр QueryBuilder вызывая статический метод whereHas (а также where(), query() или другой метод у любой модели). Дальше условия сюда добавляются через чейнинг. Where() предполагает пару вариантов аргументов: либо 2 переменные (первой идет название поля, второй ожидаемое значение — считается, что между ними стоит "равно"), 3 переменные (тогда передается еще оператор ‘>’ или ‘<’, ‘=’, like и т.п.). В качестве аргумента может передаваться также функция для группировки условий. У такого подхода есть плюсы:
ORM система Django опирается на два метода: filter и exclude. Как можно догадаться из названия, первый оставляет в выборке только то, что попадает под условия в него переданные, второй наоборот ”исключает”. Для методов filter и exclude используется свой синтаксис именованных аргументов (не похожий на SQL-запросы), который позволяет взаимодействовать с полями модели просто по их названию, а для перехода к вложенным сущностям используется двойное нижнее подчеркивание, например, timetable_ _schedule_ _code=self.userprofile.education_form.code
Это значит, что у GradeBook есть поле timetable, которое содержит сущность с полем schedule, которое в свою очередь содержит сущность с полем type, а уже оно содержит поле code.
Также для неравенств есть возможность добавлять на конец названия аргумента через двойное нижнее подчеркивание isnull, gte, lte и т.п. Подход отличается от подхода в Laravel, но какой из них сложнее — ответить сложно, скорее, это дело привычки и предпочтений разработчика.
Рекомендуем: Модели жизненного цикла, принципы и методологии разработки программного обеспечения
В Ларавел контроллеры лежат в папке http/Controllers/Api. В контроллерах Ларавел нет ничего необычного, все просто и понятно. 
В Django подход отличается, контроллеры называются views. Здесь принято использовать встроенные дженерики (generic views), содержащие набор неких готовых решений, пример ниже:
Видим, что класс наследуется от TemplateView — это джанговский дженерик, который умеет рендерить шаблон и передавать в контекст этого шаблона переменные, полученные из запроса. Также этот класс наследуется от BaseView. BaseView — объект, который примешивает к ответу стандартные вещи, в нашем случае — meta-теги и т.д. Дженерики позволяют императивно добиться нужного результата в противовес более декларативному подходу у Ларавел.
В Ларавел маршруты определены файлами в папке routes, лежащей в корне проекта: api.php, channels.php, console.php, web.php. В web попадают обычные роуты, которые должны возвращать шаблоны. Channels.php нужен для realtime-соединений, к примеру, веб-сокетов. Через console.php можно создавать консольные команды для Artisan — интерфейса командной строки, входящей в состав Ларавел.
Самый простой маршрут в Laravel состоит из URL и функции-замыкания. Роуты также можно группировать через метод group — задавать префикс пути для наборов маршрутов, а не указывать для каждого по отдельности. Сюда сначала передается некий массив с настройками, префикс для ULR’а, namespace, тип запроса (get, post) и т.д. В контроллеры также можно передавать аргументы {id}, шаблонные пути.
Удобно, что роуты лежат в одном файле — особо не запутаешься.
У Джанго у каждого приложения в главной папке есть файл urls.py, в котором заданы пути:
Также некоторые дженерики позволяют генерировать набор URL'ов для себя:
Можем подключить сюда другой файл urls или роут, сгенерированный дженериком. Подход к маршрутизации здесь похожий, но адреса раскиданы по разным файлам, что на практике может не всегда быть удобно.
У Django очень удобный встроенный интерфейс администратора, который автоматически генерируется при создании приложения. В Laravel нет встроенной админки, но для нее существуют готовые консоли, например, Laravel Nova от разработчиков платформы. Nova — это single page application, и устанавливается она буквально одной командой. Nova платная, но вы найдете много бесплатных административных панелей или можно собрать собственную, как это сделали мы.
Источник: nova.laravel.com
Специально для вас: Celery & Flower: построение и настройка очередей
На этот вопрос однозначно ответить сложно. Оба инструмента мощные и по сути делают то же самое. Каждый из подходов, используемых в этих фреймворках, для одних разработчиков окажется комфортным, а для других — нет.
По сравнению с Ларавел, который удобный и интуитивный, Джанго поначалу мне казался непонятным и запутанным. Но если втянуться в дженерики и некоторые другие особенности, то и с ним работать будет комфортно. Плюс в том, что компоненты не нужно писать с нуля — просто импортируй и используй.
Laravel очень гибкий в том плане, что под него есть много инструментов, заточенных под те или иные нужды, например, Telescope — помощник для отладки приложений, а также большое комьюнити. Django более монолитный, считается, что он не слишком подходит для небольших проектов. В любом случае выбор лучшего инструмента будет зависеть от ваших задач и требований.
Если вам нужна помощь в разработке или реализации идеи, обращайтесь к нам.
