Попри популярність та затребуваність розробки мобільних застосунків, технології веб-розробки розвивалися не менш стрімко. Популярність JavaScript, як єдиного інструменту для маніпуляції даними та об'єктами веб-документа, привнесла багато до сфери веб-розробки, особливо з появою нових концепцій: Progressive Web Applications, Accelerated Mobile Pages та Single Page Applications. Однак від цього розробка не стала простішою, вона вимагає специфічних навичок та знань, особливо від фахівців-початківців.
Безліч технологій та можливостей, але відсутність єдиного рішення для будь-яких ситуацій, зробило важким та ускладнило вибір відповідного стека для розробника. Тому ми спробуємо пролити світло на ці проблеми та розглянути два інструменти: Django та Laravel, які є одними з найпопулярніших фреймворків для серверної частини мережі.
Але, для початку, давайте зупинимося та з'ясуємо, що собою являє фреймворк як такий.
Що являє собою фреймворк
Поняття фреймворк – це абстрактний термін, який містить у собі концепцію відволікання від несуттєвих та поганих аспектів програми й концентрацію на найзначиміших з них. Ми використовуємо поняття абстракції не лише у сфері програмної інженерії, а й у нашому повсякденному житті.
Проведемо аналогію. Нам не потрібні знання термодинаміки для того, щоб навчитися керувати автомобілем чи літаком. Нам досить зрозуміти процеси взаємодії пілота із цими, досить складно влаштованими механізмами. Тобто ми сприймаємо автомобіль як абстракцію, за якою прихований весь титанічний досвід людства протягом останніх 100 років еволюції індустрії. І все, що нам потрібно - просто крутити кермо й натискати на педалі. Решта відбувається без нашого втручання й не передбачає глибоких знань у різних галузях фізики. У програмних термінах можна сказати, що нам необхідно вміти використовувати інтерфейс автомобіля.
Перевага такого підходу в програмній індустрії полягає у тому, що недосвідченому програмісту-початківцю досить просто включитися до гри, використовуючи ті інструменти, які розроблені професіоналами своєї справи й не вимагають глибокого розуміння принципу дії. Достатньо знати, як використовувати той чи інший прикладний програмний інтерфейс (API). Мало того, вам не потрібно щоразу винаходити те, що вже написано, протестовано та введено в експлуатацію.
Існує два основні рівні абстракції програмних продуктів – фреймворк та бібліотека.
Бібліотека – це набір методів чи об'єктів, які вирішують конкретне завдання в якийсь один спосіб. Розробник сам приймає рішення, яка з бібліотек найкраще підходить для поставленого завдання. Після цього завдання вирішуватиметься лише обраним способом та ніяк інакше.
А Фреймворк має чіткішу та складнішу структуру. Він надає цілий скелет майбутньої програми.
Використання фреймворку позбавляє вас необхідності створювати інфраструктуру на низькому рівні. Ви можете зосередитися виключно на бізнес-логіці програми, що, безумовно, призводить до створення програми вищого класу. Ви вирішуватимете що робити, а не як це робити.
Існує дві фундаментальні категорії фреймворків у веб-розробці.
Фронтенд-фреймворки призначені для побудови застосунків на стороні клієнта, тобто браузера. Вони оперують такими технологіями, як JavaScript та CSS. Серед найпопулярніших можна виділити React Vue та Angular. Їх використання давно стало звичною практикою фронтенд-розробника.
Бекенд-фреймворки відповідають за серверну частину програми. Це та магія, яка відбувається всередині сервера та збирає всі складові веб-сайту. Як працювати з даними, де їх зберігати, як діставати відповідно до привілеїв користувача та інше.
Кожен фреймфорк вирішує кілька ключових завдань.
Роутінг
Коли сервер обслуговує запит, він прив'язує потрібну функцію з певним URL (інтернет-адресою ресурсу). Якщо ви зайшли на сторінку, що закінчується на product/list, має спрацювати контролер, який відповідає цій адресі та сформувати відповідь зі списком товарів, попередньо отриману з бази даних. Роутінг якраз й вирішує це завдання шляхом зіставлення адреси з маскою. Зазвичай використовуються регулярні вирази для пошуку збігів рядка адреси з програмною функцією чи класом.
Ось так можна зобразити процес маршрутизації у Django.
Наприклад, ось так може виглядати один роутинг у проекті Django:
router.register(r'documents/list', DocumentListFunction)
Де зв'язування здійснюється передачею двох параметрів функції-роутера. Перший визначає шаблон рядка запиту, другий - функцію-контролер, яка буде викликана у випадку збігу URL із заданим шаблоном-маскою. У шаблоні ми можемо вказувати змінні параметри та правила, які ці параметри мають дотримуватися.
Правила описують у вигляді регулярних виразів, які можуть бути складними. Наприклад, якщо ми хочемо, щоб частина адреси складалася лише з 4 груп чисел, розділених дефісом (кредитна картка). Цей регулярний вираз може набути ось такого вигляду:
^(?:4[0-9](?:[0-9])?|[25][1-7][0-9]|6(?:011| 5[0-9][0-9])[0-9]|3[47][0-9]|3(?:0[0-5]|[68][0 -9])[0-9]|(?:2131|1800|35\d)\d)$
Шаблонізація
У разі використання фронтенд-фреймворку, такого як Angular або React, все, що потрібно від серверної частини – передати структуровані дані у вигляді масиву, наприклад, такого як json-об'єкт зі списком товарів.
[
{«name»: «Car»},
{«name»: «Airplane»},
...
]
Фронтенд-фреймворк перебирає завдання показувати цей список на html-сторінці. Він вирішуватиме де та як вивести цей список. У разі відсутності фронтенд-фреймворку ми маємо зібрати цю сторінку на стороні серверного та передати до браузера.
Саме тому й існує система шаблонізації. Спеціальний шаблонизатор поєднуватиме дані, які прийшли з контролера, з шаблоном (спеціально оформлена html сторінка). По суті, шаблонізатор просто розміщує у шаблоні дані згідно з алгоритмом, що описує логіку їх відображення. Наприклад, якщо вам необхідно прикрасити парні та непарні рядки у таблиці або вивести відповідне повідомлення у разі відсутності даних, у разі відсутності даних – все це стосується не бізнес-логіки, а логіки шаблону, тобто логіки відображення.
Прикладом відображення попередніх даних у шаблоні Django може бути наступний код:
Goods
{% for g in goods %} Name: { } {% endfor %} Приклад того ж для Laravel. @foreach ($g as $goods) {{$g['name']}} @endforeach
Як видно, шаблон використовує свою власну мову й в даному прикладі проходить масив даних, переданих з контролера. І звичайно, поруч із циклами можна використовувати й умовні оператори.
Слід зазначити, кожен фреймворк має свій власний шаблонізатор й відповідно свій шаблонний синтаксис. Але їх усі часто об'єднує використання символів {} [] % $ @ як позначки, куди «опускаються» наші змінні, найчастіше у вигляді досить складних ієрархічних структур, або позначаються логічні оператори.
ORM (object-relational mapping)
Цю технологію можна перевести як об'єктно-реляційну проекцію взаємопов'язаних даних. Де схема або опис структури даних, які в термінах фреймворків називають моделлю засобами, ORM зв'язується з фізичною базою даних, таких як MySQL або PostgreSQL та є шаром абстракції між моделлю й базою. Іншими словами, це сукупність програмних класів та об'єктів, які проектуються у фізичні таблиці та записи. У Django та Laravel класи моделі представляють таблицю, об'єкти – записи, а їх атрибути (у Django) – поля таблиці.
Приклад моделі Django:
від 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-]-[0-9]');
Route::get('', 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.
Підсумовуючи, наведемо порівняльну таблицю з усього вище сказаного.
|
Технологія |
Django |
Laravel |
|
Мова, технологія |
Python, MVT |
PHP, MVC |
|
Безпека |
високий рівень |
базовий рівень |
|
GitHub рейтинг |
43 384 |
34 292 |
|
Освоєння |
легке |
крутіше |
|
Продуктивність |
висока |
середня |
|
Кількість сайтів |
205 106 |
121 173 |
|
API |
У зв'язці з JS фреймфорками складний і вимагає додаткових плагінів |
Легкий підтримує vue.js з коробки |
