Django или Laravel

Несмотря на растущую популярность и востребованность разработки мобильных приложений, технологии веб-разработки развивались не менее стремительно. Популярность JavaScript, как единственного инструмента для манипуляции данными и объектами веб-документа, привнесла многое в сферу веб-разработки, особенно с появлением новых концепций: Progressive Web Applications, Accelerated Mobile Pages и Single Page Applications. Однако от этого разработка не стала проще, она требует специфических навыков и знаний, особенно от начинающих специалистов.

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

Но, для начала, давайте остановимся и разберемся, что из себя представляет фреймворк как таковой.

Содержание

• Что из себя представляет фреймворк
• Роутинг
• Шаблонизация
• ORM
• Код
• Комьюнити
• Освоение
• Продуктивность
• Безопасность
• API

Что из себя представляет фреймворк

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

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

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

Существует два основных уровня абстракции программных продуктов – фреймворк и библиотека.

Библиотека – это набор методов или объектов, которые решают конкретную задачу и каким-то одним способом. Разработчик сам принимает решение, какая из библиотек лучше подходит для поставленной задачи. После этого задача будет решаться только выбранным способом и никак иначе.

Фреймворк же, имеет более строгую и сложную структуру. Он предоставляет целый скелет будущего приложения.

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

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

Фронтенд-фреймворки предназначены для построения приложений на стороне клиента т. е. браузера. Они оперируют такими технологиями как JavaScript и CSS. Среди наиболее популярных можно выделить React Vue и Angular. Их использование давно стало обычной практикой фронтенд-разработчика.

Web-разработка

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

ПОДРОБНЕЕ

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

Каждый фреймфорк решает несколько ключевых задач.

Роутинг

Когда ваш сервер обслуживает запрос, он привязывает нужную функцию с определенным URL (интернет-адресом ресурса). Если вы зашли на страницу, оканчивающуюся на product/list, должен сработать контроллер, соответствующий этому адресу и сформировать ответ со списком товаров, предварительно полученный из базы данных. Роутинг как раз и решает эту задачу путем сопоставления адреса с маской. Обычно используются регулярные выражения для поиска совпадений строки адреса с программной функцией или классом.

Вот так можно изобразить процесс маршрутизации в Django.

Например, вот так может выглядеть один роутинг в проекте Django:

router.register(r'documents/list', DocumentListFunction)

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

Правила описывают в виде регулярных выражений, которые могут быть довольно сложными. Например, если мы хотим, чтобы часть адреса состояла только из 4 групп чисел, разделенных дефисом (кредитная карта). То регулярное выражение может принять вот такой вид:

^(?:4[0-9]{12}(?:[0-9]{3})?|[25][1-7][0-9]{14}|6(?:011|5[0-9][0-9])[0-9]{12}|3[47][0-9]{13}|3(?:0[0-5]|[68][0-9])[0-9]{11}|(?:2131|1800|35\d{3})\d{11})$

Шаблонизация

В случае использования фронтенд-фреймворка, такого как Angular или React, все что требуется от серверной части – передать структурированные данные в виде массива, например такого как json объект со списком товаров.

[
   {«name»: «Car»},
   {«name»: «Airplane»},
   ...
]

Фронтенд-фреймворк берет на себя задачу отображать этот список на html-странице. Он будет решать где и как вывести этот список. В случае же отсутствия фронтенд-фреймворка мы должны собрать эту страницу на стороне серверного и передать в браузер.

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

Примером отображения предыдущий данных в шаблоне Django может быть следующий код:

Goods

{% for g in goods %}
Name: {
    { g.name }
}    
{% endfor %}
Пример того же для Laravel.
@foreach ($g as $goods)
{{$g['name']}}
        @endforeach

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

Следует отметить, что каждый фреймворк имеет свой собственный шаблонизатор и соответственно свой шаблонный синтаксис. Но их все, зачастую, объединяет использование символов {} [] % $ @ в качестве меток, куда «опускаются» наши переменные, зачастую в виде довольно сложных иерархических структур, или обозначаются логические операторы.

ORM (object-relational mapping)

Эту технологию можно перевести как объектно-реляционная проекция взаимосвязанных данных. Где схема или описание структуры данных, которые в терминах фреймворков называют моделью по средствам, ORM связывается с физической базой данных, таких как MySQL или PostgreSQL и представляет собой слой абстракции между моделью и базой. Другими словами, это совокупность программных классов и объектов, которые проецируются в физические таблицы и записи. В Django и Laravel классы модели представляют таблицу, объекты — записи, а их атрибуты (в Django) — поля таблицы.

Пример модели Django:

from django.db import models
class City(models.Model):
name = models.CharField(max_length=250)
class User(models.Model):
name = models.CharField(max_length=250)
description = models.TextField(blank=True, null=True)
birthdate = models.DateField(blank=True, null=True)
is_admin = models.BooleanField(default=False)
city = models.ForeignKey(City, on_delete=models.SET_NULL)

Как видно, каждое поле таблицы представлено атрибутом класса с указанием его типа, размерности, значением по умолчанию и т.д. Взаимосвязь между таблицами определяется отдельными атрибутами типа ForeignKey , OneToOne или ManyToManyField, в зависимости от типа связи.

В Laravel же, определять поля таблицы не обязательно. Достаточно создать класс наследник и переопределить нужные вам методы по извлечению или изменению данных. Так же, с помощью этих методов, мы определяем и связи между моделями. Дело в том, что Laravel, впрочем как и Django, по умолчанию будет запрашивать все поля из таблицы select * и затем внедрять (гидрировать) данные полей в массив объектов модели. Явное же указание полей в Джанго позволяет не привязываться к физической структуре таблиц. И при создании форм для CRUD операций, к примеру, у нас будет единый источник информации о структуре нашей модели.

Пример модели Laravel:

Это MVT (model view template) фреймворк, построеный на языке python. Это продукт с открытым и бесплатным исходным кодом, который обеспечивает быструю разработку и помогает написать короткий и эффективный код. Это очень мощный инструмент с богатой инфраструктурой и используемый такими компаниями как Udemy, Pinterest, NASA, и Instagram.

Laravel

Это MVC (model-view-controller) фреймворк, написанный на PHP, одним из наиболее популярных языков в вебе. Это также очень мощный инструмент, используемый такими компаниями как 9GAG, UNION, Toyota, Wezom и .т.

Отличие MVC от MVT незначительно, и заключается в том, что при MVT или MTV вся логика отображения перекладывается на шаблон и View. Слой его связывает с моделью, а функции контроллера берет на себя сам фреймворк. Тогда когда при MVC архитектуре запрос обрабатывается контроллером и уведомляет view и model о необходимости передать и отобразить данные.

Код

Взглянем на код роутинга, написанный на обоих языках.

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

PHP:

Route:get('/', function() { return view('posts.index'); });
Route:get('/posts/create', function() { return view('posts.create'); });

Python:

urlptterns = [
path('', view.index),
re_path('^detail/(?P[\w-]+)/$', view.detail),
]

Однако это не говорит о том что вы не можете использовать мощь регулярных выражений на Laravel. Например так:

Route::pattern('product', '[a-z0-9-]{4,}-[0-9]{1,10}');
Route::get('{product}', function (){…})

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

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

Комьюнити

У Django существует очень богатое и отзывчивое сообщество как и у Laravel, поэтому на любой вопрос вы скорее всего получите ответ очень быстро. Тоже можно сказать о библиотеках и всяких дополнительных инструментах к ним. В основном, все они с открытым исходным кодом и на github можно найти плагин или пакет или библиотеку на любой вкус и под любую задачу. Оба имеют удобные установщики зависимостей, упрощающие их поиск и установку.

Например в Django зависимость можно поставить одной коммандой из файла с списком зависимостей или поштучно:

pip install package-name
pip install -r requirements.txt

В PHP принято использовать composer

composer install

Освоение

Конечно, процесс освоения этих фреймворков зависит во многом от индивидуальности человека. Если вам приятен синтаксис Python то Django станет хорошим выбором, и процесс освоения не займет много времени, особенно при наличии довольно подробной и добротной документации. Лаконичность и понятность синтаксиса python сделало его предпочтительным языком во многих вузах запада.

Laravel же не так прост в освоении как Django, но наличие таких инструментов как Laracasts и хорошая документация поможет вам потратить минимум времени на освоение.

Продуктивность

Laravel и Django были протестированы в 2018 году в задачах сериализации JSON. И благодаря тому, что эволюция python положительно отразилась на скорости его работы, он одержал верх, причем значительно оставив Laravel позади.

http://www.techempower.com/benchmarks/#section=data-r16&hw=ph&test=json

Он потянул 69к запросов в секунду против 8 для Laravel. Так что в отношении скорости, Laravel, к сожаленью не смог конкурировать с Django.

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

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

API

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

Хорошая новость в том, что Laravel поставляется со встроенной поддержкой для построения API. Все ответы по умолчанию возвращаются в формате json.

Django не имеет такого из коробки и требует установки дополнительных библиотек (пакетов в терминах питон) для построения RESTfull API.

Наиболее продвинутым является Django REST framework.

Подводя итог, приведем сравнительную таблицу по всему выше сказанному.