У цій статті я хочу поговорити про те, який веб-фреймворк обрати для вивчення чи реалізації проекту. Flask чи Django.
Отже, якщо з Django все більш-менш зрозуміло, що це популярний фреймворк, має велике ком’юніті, на яке у випадку виникнення проблем можна звернутись за допомогою, то Flask – це, зазвичай, така собі темна конячка, від котрої невідомо що очікувати. І ось тут мені, скоріш за все, потрібно коротенько розказати, що у цих фреймворків під капотом.
Для початку я хочу одразу відмітити, що і Flask і Django пропонують дві діаметрально протилежні точки зору на розробку. Або, якщо хочете, два підходи до розробки веб-додатків.
Flask
Почну з Flask. Якщо вам доводилось опрацьовувати tutorial, то ви знаєте, що Flask після установки представляє собою всього дві компоненти. Це Jinja та Werkzeug.
Перша компонента Jinja – це звичайний шаблонізатор, який дозволяє у існуючу зверстану HTML-сторінку підставити у потрібні місця згенеровані або витягнені з БД дані. І все. В цьому вся суть шаблонізатора Jinja.
Друга компонента Werkzeug – це навіть ніякий не фреймворк. Це просто маршрутизатор запитів. Такий собі набір функцій для обробки запитів і спрямування відповідей на запити. Також він забезпечує сумісність зі специфікаціями WSGI, щоб можна було використовувати Flask із серверним софтом типу Apache чи nginx. Ось і все.
Тобто, по суті, Flask з коробки в дефолтному стані – це просто маршрутизатор запитів. Більше у нього немає нічого.
Flask передбачає, що все інше, що може знадобитись для реалізації функціоналу ми або пишемо самі або встановлюємо і налаштовуємо вже існуючі модулі. У технології Flask це називається Blueprint.
Творець Flask назвав його мікрофреймворком, хоча насправді більше підійшла б назва мінімалістичний фреймворк, так як Flask – це мінімалізм у чистому вигляді. І справді, все, що необхідно для початку є, все інше ти робиш сам.
І цей ярлик “мікрофреймворк”, як я помітив, багатьох вводить в оману. Доволі часто доводиться бачити у коментарях на форумах таку думку, що Flask годиться виключно для написання мікрододатків, якихось маленьких, зроблених “на коліні” додатків, свого роду прототипів і навряд чи може бути використаний для чогось більш серйозного.
Це, власне, докорінно невірне бачення. Flask – доволі серйозний фреймворк і пізніше я наведу приклад одного дуже популярного сервісу, який використовує Flask.
Django
Тепер декілька слів про Django. У нього зовсім інша позиція. У коробці фреймворка є все, що необхідно. Взагалі геть усе необхідне для розробки веб-додатків типу магазину, каталогу, дошки оголошень, біржі чи маркетплейса або блогу. Тобто, все, що вкладається у нашу уяву про якісь стандартні функції дуже легко реалізуються з Django.
У коробці Django є своє власне ОРМ для роботи з базою даних, свій маршрутизатор, свій повноцінний фреймворк автентифікації користувача, зберігання та шифрування паролів, сесій, механізми міграції, є своя адмінка, засоби для роботи з формами, карта сайту, а також засоби для створення E-mail розсилок. Тобто, все, що лише може знадобитись, там вже є.
Оце все є і воно є одразу після встановлення Django за допомогою pip. Ці речі потрібно, звичайно, дещо підналаштувати, але воно все вже є під рукою і можна використовувати в своїх цілях.
Всі ці компоненти та applications чудово взаємодіють між собою, добротно зроблені та, на мій погляд, мають досить сильний взаємозв’язок.
Це, з одного боку, дає відмінний функціонал, який одразу працює “так як треба” і не потрібно, практично, нічого підганяти та налаштовувати окремо. Не потрібно писати ніяких обв’язок для цих компонент, на відміну від Flask.
З іншого боку, у деяких ситуаціях цей такий сильний взаємозв’язок між компонентами дуже складно кастомізовувати. Друга справа, чи потрібна взагалі кастомізація, але тим не менш.
Багато хто лається на джангівську ОРМ. Так, у неї є проблеми, вона генерує неефективні запити до бази даних, але для 95% усіх ситуацій штатної ОРМ вистачить з головою. І якщо люди зіткнулись з якимись проблемами при роботі з ОРМ, то, зазвичай, вони або переходять на SQLAlchemy, або переписують потрібні запити руками.
На відміну від Flask, Django дозволяє реалізувати робочу версію додатку дуже швидко.
Що обрати новачку?
Окей, ти скажеш “з цим все ясно, але як мені обрати, що вивчати…”. Я вважаю так. Якщо твоя мета вивчення засобів для розробки веб-додатків, то вивчати потрібно і Flask, і Django. При цьому рекомендую починати з Flask, а вже потім переходити до Django.
Чому саме в такій послідовності? Тому що Flask у порівнянні з Django, більш низькорівневий і тут доводиться багато працювати руками.
На початковому етапі це дуже важливо тому, що така ручна робота формує розуміння про роботу веб-фреймворків на низькому рівні та дозволяє побачити що у них під капотом. А вже після цього, на основу, яку дає Flask, Django лягає дуже добре та його вивчення проходить значно швидше і легше. Все ж таки Django тяжче дається, бо в ньому все є і все треба вивчати.
Ідея зрозуміла. Від простого до складнішого, від низького рівня до більш абстрактного – від Flask до Django.
Проекти
Тепер про проекти. А точніше, наскільки великі проекти можна реалізувати на цих фреймворках.
Почну з Django. Найбільша реалізація проекту на Django – це Instagram, котрий досі працює на цьому фреймворку. У 2017 році Instagram перейшов на Python 3.
Про це є досить цікава стаття з розробниками Інсти, яка була опублікована у червні 2017 року. Називається вона “Instagram makes a smooth move Python 3”. Якщо цікаво, почитайте.
У статті автор описує проблеми, з якими зіткнулись розробники, розказують про технологічний стек, який використовується соціальною мережею Instagram. І цей стек Django. Так, можливо, з певними ньюансами. Так, можливо, дещо довелось переписати. Тим не менш.
Масштаб проекту Instagram всім відомий. Доречним буде згадати, за яку суму у 2012 році Facebook купив Instagram – 1 мільярд доларів США!
Це завжди доречно згадувати, особливо тоді, коли хтось лається на мову програмування Python, мовляв це відстій і що справжні проекти пишуться на C, C++ та Java. Попри все, з моменту появи Instagram у 2010 році через 2 роки його оцінили у мільярд доларів. І це ще досі Python і Django.
Наступний приклад проекту на Django – навчальна платформа Udemy з онлайн-курсами.
І ще один досить масштабний проект Discuss – система коментарів, теж написана на Django.
Тепер про Flask. Тут взагалі дуже цікаво. Технологічний стек Pinterest у 2011 році базувався на Django. Це був дуже сильно урізаний та модифікований фреймворк Django та вибірково Tornado для обробки асинхронних запитів. А от з кінця 2011 року даний сервіс перейшов на Flask. Розробниками було розроблено API на Flask.
Про проблеми переходу сервісу на цей фреймворк написав API-розробник Pinterest Стів Коен у статті на Quora, яка називається “What challenges has Pinterest encountered with Flask”. Там пишеться про те, що Flask щоденно обробляє понад 12 мільйонів запитів до API Мені здається – це хороший результат!
Рекомендації
Насправді, рекомендацій небагато.
Якщо важлива швидкість розробки і у вас вже є якісь типові проблеми стандартної задачі, які вже мали рішення раніше, то однозначно потрібно користуватись Django, він більше підійде.
З іншого боку, якщо у вас вже є проект з реалізованим front-end на сучасному фреймворку на кшталт Angular, React, Vue, тощо або мобільний додаток і вам потрібен back-end для реалізації тільки API, то однозначно Flask.
Для проектів, в яких не потрібен фронт-енд, також рекомендується використовувати фреймворк Flask.
Власне, щоб зрозуміти краше, потрібно попрацювати з обома фреймворками, зробити декілька однакових проектів на них. А також декілька проектів з REST. Для цього є відповідні blueprint для Flask – RESTful та відповідно Django REST Framework. Зробити парочку проектів чистого коду API. Подивитись як це все працює, помацати на практиці.
Після реалізації навіть нескладних проектів автоматично прийде розуміння в яких ситуаціях який фреймворк використовувати і подібні питання самі собою відпадуть.
Отже, при виборі фреймворка для розробки проекту потрібно керуватись, перш за все, завданнями, які ставляться перед проектом.
