Комментарии 66
В 2017-м можно уже и aiohttp юзать для этих целей, если API реально простое.
А что с ним не так? Стабильная версия больше 1.0.0 имеется, в официальной документации рекомендации по использованию в продакшене есть, т.е. такое использование подразумевается. Я знаю несколько компаний, где он используется в продакшене. Причем в одной из них к этому приложил руку я, причем сфера услуг — финансы, т.е. требования к стабильности высокие. Потому мне очень интересно узнать, чем он не готов к продакшену?
+ один из 100500 новомодных мини-фреймворков (например gin).
А нет? — используй Django. Как бы странно это не звучало…
Нарывался я уже на «чудо-минималистичный» код на flask'e.
Когда чувак думал, что нужна всего одна вьюха, а в итоге…
После того как я увидел какие запросы к базе делает Django ORM я больше не могу его использовать.
Данный пример явно выдран из контекста. Скорее всего это второй запрос и двух после применения refetch_related — что на самом деле является как раз оптимизацией. Альтернатива такому запросу — запрос каждой сущности из table (точнее из другой, которая заранее читается при помощи prefetch_related) по одному.
Пропущено, вы правы. Это из статьи "Производительность запросов в PostgreSQL". В статье такие оптимизации ORM предлагают ускорить кастованием списка id в ResultSet с помощью конструкции VALUES (или можно ждать N лет, пока postgres станет ещё умнее). Но вот от проблемы передачи этих самых id по сети это не избавляет. Почему-то есть уверенность, что такую задачу эффективно и универсально никто не умеет решать. И по-моему тут уже становится ясно, что ORM не так и плох, а надо искать компромисс (как обычно)
Есть интуитивное ощущение, что в некоторых случаях prefetch_related можно было бы сделать более эффективным. Но в код не лазил, не знаю, насколько это сложно.
Честно говоря, не понимаю наездов на Django ORM и ORM вообще. Единственная часто встречающаяся ситуация, в которой он генерирует кривые запросы — это prefetch_related. Автор той презентации нашел самую удачную цель для критики и не предложил никакой альтернативы. А она существует?
Запросы пишет не Django ORM, а человек. Django ORM — это инструмент. Если человек не понимает/не знает как работает инструмент — это проблема человека, а не инструмента.
Если с Django ORM действительно что-то не так — у человека есть возможность исправить инструмент.
А какой ORM лучше?
Я много занимался оптимизацией запросов Django и ничего криминального не видел. Плохой код на Python приводит к генерации плохого SQL. А разве где-то бывает иначе?
Flask в купе с json-schema отлично подходит для голых API серверов с отдельным фронтом или же вообще без него.
Тестирую через pytest-flask и наслаждаюсь.
Проблема с роутами неплохо так решается без проблем через @blueprint.route('/url', methods=["POST"])
form = EditFooForm(obj=foo_obj)
form.foo.choices = current_app.config['FOO_CHOICES']
С остальными проблемами не сталкивался, видимо пока везет :)
Использую flask_login, flask_restful, flask_wtf и flask_sqlalchemy — все работает вполне неплохо, включая тестирование через test_client.
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. Хабр, ты почему не типографишь тексты?
Потому что для языка на котором написан хабр нет вменяемого типографа :(
ps: и да, flask нуждается в популяризации, но только адекватными методами, чтобы не превратить его в очередную кучу джанга
За typus — отдельное спасибо!
Еще в повседневных условиях понравился aiohttp — но он скорее альтернатива фласку чем джанге. Очень хорош для асинхронных апи.
Еще в повседневных условиях понравился aiohttp — но он скорее альтернатива фласку чем джанге
Сравнивая фреймворк на эвентлупе, надо сравнивать его с любым другим фреймворком на эвентлупе — не с синхронным фреймворком.
Спасибо, на здоровье.
Я работаю с джангой. В мире python аналогов, в общем-то, нет. До недавнего времени я был уверен, что flask способен составить конкуренцию. А теперь все.
class Foo(FlaskForm):
choices = SelectField(choices=app.conf.FOO_CHOICES)
Мне кажется, какой-то синтетический случай. Такbе параметры у меня, если и захардкожены, то лежат вместе с моделями в models.py
- пишем приложение, которое работает с пабликами в соц. сетях. На проде один список (настоящих), на тестовом — тестовый.
- загрузка картинок: в проде один путь, на деве другой (локальный).
- дефолтный имел для отсылки чего-либо: на проде один — ну вы поняли.
Занесите это в сеттинги и бед знать не будете.
Но у меня опыт маленький — я писал давно на php3 с перлом, а в отрасль вернулся только пару лет назад для своего проекта и сразу стал изучать питон и фласк, и даже картинки все у меня в базе.
Посмотрите вот тут. Не знаю как по-другому объяснить. Если коротко: парсить файлы — это вообще атас. Вот, как выглядит файл конфига моего сайта на фласке. Видите, как легко читается?
В первую очередь: наследование. Общий класс конфига и далее вариации для раличных кейсов. Это такая частная реализация пакета django-configurations, только на фласке. Забавно, что фласк это умеет сам, а джанга — нет.
Теперь отметьте, что присутствуют настройки для отдельных приложений (формы, бейбл и т.д.). Это тоже привычная практика: приложение определяет внутри пакета конфигурацию по-умолчанию. А в мастер-конфигурации переопределяются специфичные для проекта настройки. Тоже своеобразное наследование.
Релевантный пост на хабре.
Демо с "елочками".
Пример в ридми.
Местами приходится использовать прокси (в аду должен быть отдельный thread-locals-котёл), бывают проблемы с перекрёстными импортами, дурацкий init_app(). И когда наконец получается хорошо структурированное приложение, оно удивительным образом напоминает джангу.
И ещё одно: не следует рассматривать блюпринты как аналог Django apps. Это просто способ чуть удобнее структурировать код, если проект начал пухнуть. Flask extensions больше похожи, например, flask-debugtoolbar.
Вы каким-то образом всю мою статью одним комментарием рассказали. Фласк плохо растет, а когда его приводишь в нормальный вид, получается джанга. Кстати, я все еще пользуюсь фласком, джангой на работе наедаюсь.
В статье собраны грабли, она не призвана отговорить использовать фласк.
Джанга подходит и для очень крупных проектов. Некоторые ее части можно бы сделать лучше, некоторые так и делают. Однако, есть крайне важный момент, который окупает все ее недостатки: у джанги очень большое комьюнити, очень много батареек, очень много вкусного появляется от релиза к релизу, и, самое главное, она развивается по принципу совместимости. Я уверен, что могу взять средний проект для 0.9 и за пару часов прикрутить туда 1.10. А разница по времени релизов огромная.
Фласк я использую и буду ) Потому что люблю экспериментировать. В нем, кстати, некоторые штуки реализованы по-лучше, чем в джанге.
Я работал с несколькими огромными проектами на Django. Никаких проблем, затыки начинаются вовсе не из-за ограничений Django, а из-за производительности БД, организации данных и эффективности алгоритмов.
У меня наверное предвзятое мнение, т.к. в основном я уже много лет использую Django, а другие фреймворки либо недолго щупал, либо использовал эпизодически. Но Django удивительно подходит для проектов любого масштаба. С моей точки зрения.
Публикации
What the flask?