Как стать автором
Обновить

Комментарии 66

Там даже на одном из пайконов парень рассказывал, почему flask — можно использовать для себя, но для продакшена — это настоящее мучение.
Ну что вы так сразу =) ИХМО Фласк самое то для микросервисов. У меня на флаксе написано одно довольно простое API
А он уже готов к production?

А что с ним не так? Стабильная версия больше 1.0.0 имеется, в официальной документации рекомендации по использованию в продакшене есть, т.е. такое использование подразумевается. Я знаю несколько компаний, где он используется в продакшене. Причем в одной из них к этому приложил руку я, причем сфера услуг — финансы, т.е. требования к стабильности высокие. Потому мне очень интересно узнать, чем он не готов к продакшену?

Вполне. Участвовал в написании не самого маленького проекта на нём в середине 2016. Даже понравилось.
Если уж хочешь поизвращаться пиши на Go
+ один из 100500 новомодных мини-фреймворков (например gin).

А нет? — используй Django. Как бы странно это не звучало…

Нарывался я уже на «чудо-минималистичный» код на flask'e.
Когда чувак думал, что нужна всего одна вьюха, а в итоге…

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

Например?
image

такое впечатление, что на слайде пропущено слово WHERE.

Данный пример явно выдран из контекста. Скорее всего это второй запрос и двух после применения refetch_related — что на самом деле является как раз оптимизацией. Альтернатива такому запросу — запрос каждой сущности из table (точнее из другой, которая заранее читается при помощи prefetch_related) по одному.

Пропущено, вы правы. Это из статьи "Производительность запросов в PostgreSQL". В статье такие оптимизации ORM предлагают ускорить кастованием списка id в ResultSet с помощью конструкции VALUES (или можно ждать N лет, пока postgres станет ещё умнее). Но вот от проблемы передачи этих самых id по сети это не избавляет. Почему-то есть уверенность, что такую задачу эффективно и универсально никто не умеет решать. И по-моему тут уже становится ясно, что ORM не так и плох, а надо искать компромисс (как обычно)

Есть интуитивное ощущение, что в некоторых случаях prefetch_related можно было бы сделать более эффективным. Но в код не лазил, не знаю, насколько это сложно.


Честно говоря, не понимаю наездов на Django ORM и ORM вообще. Единственная часто встречающаяся ситуация, в которой он генерирует кривые запросы — это prefetch_related. Автор той презентации нашел самую удачную цель для критики и не предложил никакой альтернативы. А она существует?

НЛО прилетело и опубликовало эту надпись здесь
И в итоге у вас получится собственный ORM.

Запросы пишет не Django ORM, а человек. Django ORM — это инструмент. Если человек не понимает/не знает как работает инструмент — это проблема человека, а не инструмента.


Если с Django ORM действительно что-то не так — у человека есть возможность исправить инструмент.

А какой ORM лучше?
Я много занимался оптимизацией запросов Django и ничего криминального не видел. Плохой код на Python приводит к генерации плохого SQL. А разве где-то бывает иначе?

Flask в купе с json-schema отлично подходит для голых API серверов с отдельным фронтом или же вообще без него.


Тестирую через pytest-flask и наслаждаюсь.


Проблема с роутами неплохо так решается без проблем через @blueprint.route('/url', methods=["POST"])

Я использую просто pytest. А что вам дает это расширение pytest-flask? Там, на мой взгляд, добавлено только 2-3 fixture-объекта, которые пишутся достаточно быстро.
Нууу, мне не надо писать эти 2-3 fixture-объекта самому в каждом проекте с фласком?
Зачем в каждом? Один раз conftest.py написал и всюду где надо юзаешь
По одному разу в каждом проекте…

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

choices в формах заполнять можно так:
form = EditFooForm(obj=foo_obj)
form.foo.choices = current_app.config['FOO_CHOICES']

С остальными проблемами не сталкивался, видимо пока везет :)
Использую flask_login, flask_restful, flask_wtf и flask_sqlalchemy — все работает вполне неплохо, включая тестирование через test_client.

Так можно и на инит повесить. Только это не спортивно совсем.

А скажите, пожалуйста, зачем вам flask_restful?
Я вот обнаружил, что для простых случаев он не нужен, а для сложных — flask_potion удивителен и неповторим.
Ну и лично мне peewee ORM кажется намного более удобным при написании.
НЛО прилетело и опубликовало эту надпись здесь
если нужна простая страница в вебе, то вам и Flask/Django не нужны. Фреймворки же не просто так фпеймворками называются — у них есть предназначение. И если под предназначением понимается создание пусть даже небольшого API из нескольких методов, то я предпочту не держать все в одном файле.
Необязательно создавать целый проект:

app.py
from django.conf import settings
from django.conf.urls import url
from django.http import HttpResponse

settings.configure(
    ROOT_URLCONF=__name__,
)


def index(request):
    return HttpResponse("Hello, world !")

urlpatterns = [
    url(r'^$', index)
]


if __name__ == '__main__':
    
    from django.core.servers.basehttp import run
    from django.core.wsgi import get_wsgi_application

    app = get_wsgi_application()

    run('127.0.0.1', 8888, app)

Так фласк не позиционирует себя как "одностраничный сайт". Та же система blueprints это про getting bigger — когда проект разбивается на модули. Только работает это все очень плохо.


А так да, я тоже делал сайт с одной страничкой. Так всегда начинается.

P.P.S. Хабр, ты почему не типографишь тексты?

Потому что для языка на котором написан хабр нет вменяемого типографа :(

Ммм. У typus есть веб-апи на этот случай. А на чем он написан-то, пхп?

Нее, на внешнее апи мы не можем полагаться. Но может еще что-то придумаем.

Можно запускать из консоли. Но я понимаю, хочется нативное решение.

есть не приятное ощущение, когда приличный паблик ссылается на выделение хипстера, который к тому же и лыка не вяжет

ps: и да, flask нуждается в популяризации, но только адекватными методами, чтобы не превратить его в очередную кучу джанга

Я, к сожалению, по фене не ботаю, но могу конструктивно ответить на конструктивный вопрос, если, конечно же, у вас он есть.


У фласка серьезные архитектурные ограничения. Популяризируй или нет, они никуда не денутся.

какие из представленный мной слов вы не поняли? или вы просто дурачком пытаетесь прикинуться — так у вас не получается
Отличный текст! Едкий, с толковыми примерами! А что используете в повседневной жизни? Лично я давно подсел на Джангу и невзирая на её недостатки, не вижу ей замену даже в условиях новомодных Ангуляров. Или плохо смотрю?

За typus — отдельное спасибо!
Я боюсь спросить а как новомодный ангуляр может составить конкуренцию джанге?

Еще в повседневных условиях понравился aiohttp — но он скорее альтернатива фласку чем джанге. Очень хорош для асинхронных апи.
Ангуляр тут выступает как сферический buzzword в вакууме. Не более.
Еще в повседневных условиях понравился aiohttp — но он скорее альтернатива фласку чем джанге

Сравнивая меч Хаттори Ханзо, сравнивай его с любыми другими мечами — не Хаттори Ханзо
Сравнивая фреймворк на эвентлупе, надо сравнивать его с любым другим фреймворком на эвентлупе — не с синхронным фреймворком.
Почему нет? Авторы не скрывали что хотели сделать нечто подобное фласку но на евентлупе и без его архитектурных недостатков.

Спасибо, на здоровье.
Я работаю с джангой. В мире python аналогов, в общем-то, нет. До недавнего времени я был уверен, что flask способен составить конкуренцию. А теперь все.

class Foo(FlaskForm):
choices = SelectField(choices=app.conf.FOO_CHOICES)

Мне кажется, какой-то синтетический случай. Такbе параметры у меня, если и захардкожены, то лежат вместе с моделями в models.py
  1. пишем приложение, которое работает с пабликами в соц. сетях. На проде один список (настоящих), на тестовом — тестовый.
  2. загрузка картинок: в проде один путь, на деве другой (локальный).
  3. дефолтный имел для отсылки чего-либо: на проде один — ну вы поняли.

Занесите это в сеттинги и бед знать не будете.

Само собой. Но те же паблики — в текстовый файл с json, или любой другой сторадж.
Но у меня опыт маленький — я писал давно на php3 с перлом, а в отрасль вернулся только пару лет назад для своего проекта и сразу стал изучать питон и фласк, и даже картинки все у меня в базе.

Посмотрите вот тут. Не знаю как по-другому объяснить. Если коротко: парсить файлы — это вообще атас. Вот, как выглядит файл конфига моего сайта на фласке. Видите, как легко читается?


В первую очередь: наследование. Общий класс конфига и далее вариации для раличных кейсов. Это такая частная реализация пакета django-configurations, только на фласке. Забавно, что фласк это умеет сам, а джанга — нет.


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

используйте докер контейнеры для создания окружения и будет все одинаковое для прода и дева
По поводу вашей штуки для типографики: коль уж подразумевается поддержка кириллицы, то и кавычки надо кошерные ставить: «».
ребят, так а что есть достойного для написания json rest api на python? без фронта, без куков, хтмл, javascript и всего такого. голый rest api.
НЛО прилетело и опубликовало эту надпись здесь
Cornice хорошая штука. Это набор хелперов для построения REST на базе Pyramid.
НЛО прилетело и опубликовало эту надпись здесь
На фласке удобно готовить API и делать различные наброски. Все остальное — жуть.
В Flask и Django мне не нравится концепции для расширения приложения (blueprints, apps). Подход Pyramid более лаконичен, где не выходят за рамки Pyrhon пакетов. А с выходом отличного фреймворка Websauna (посути расширения Pyramid) мне кажется что больше ничего и не нужно для счастья :)
У кого-нибудь есть опыт работы с Sanic? Он позиционируется как близкий фласку по духу, но при этом асинхронный.
Ну фиг знает. У меня такие проблемы были в первом проекте на фласке, потом как-то пристрелялся в ногу.
Местами приходится использовать прокси (в аду должен быть отдельный thread-locals-котёл), бывают проблемы с перекрёстными импортами, дурацкий init_app(). И когда наконец получается хорошо структурированное приложение, оно удивительным образом напоминает джангу.

И ещё одно: не следует рассматривать блюпринты как аналог Django apps. Это просто способ чуть удобнее структурировать код, если проект начал пухнуть. Flask extensions больше похожи, например, flask-debugtoolbar.

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

Я не работал с асинхронными фреймворками на продакшене. Вернее, не работал настолько плотно, чтобы поймать какие-либо грабли. Торнадо — прекрасен, но сейчас по планете шагает py 3.6 и там тоже много вкусного. А про sanic я узнал из того комментария.

НЛО прилетело и опубликовало эту надпись здесь

В статье собраны грабли, она не призвана отговорить использовать фласк.
Джанга подходит и для очень крупных проектов. Некоторые ее части можно бы сделать лучше, некоторые так и делают. Однако, есть крайне важный момент, который окупает все ее недостатки: у джанги очень большое комьюнити, очень много батареек, очень много вкусного появляется от релиза к релизу, и, самое главное, она развивается по принципу совместимости. Я уверен, что могу взять средний проект для 0.9 и за пару часов прикрутить туда 1.10. А разница по времени релизов огромная.
Фласк я использую и буду ) Потому что люблю экспериментировать. В нем, кстати, некоторые штуки реализованы по-лучше, чем в джанге.

Я работал с несколькими огромными проектами на Django. Никаких проблем, затыки начинаются вовсе не из-за ограничений Django, а из-за производительности БД, организации данных и эффективности алгоритмов.


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

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Публикации

Истории