Pull to refresh

Comments 10

хм, а не лучше вынести отправку емейла на какой-то отдельный сервис, обрабатывающий очереди задач?
А сама по себе отправка емейла — и есть процесс передачи задачи в очередь. Процесс заключается в следующем: мы вызываем локальную доставку командой sendmail. Если это sendmail от достаточно продвинутого пакета (postfix, sendmail, exim), то он только и делает, что ставит сообщение в очередь для доставки и сразу же возвращается. А дальше уже сообщение подхватит другой демон, отвечающий за разбор этой очереди.
Люди, работающие плотно с flask, подскажите, какие у него есть преимущества перед Django?
Я, изучив его доки, сделав свой 1 проект небольшой на нем и какое-то время поучаствовав в разработке чужого большого проекта — пока никаких не увидел.
Да, я знаю (с чужих слов), что SQLAlchemy пофичастее Django ORM, а Jinja2 побыстрее рендерит шаблоны, чем джанговский движок. Но, это не сам flask. А чем же flask-то лучше? Я вижу, что большинство внешних расширений для flask пытаются из него джангу сделать.
Так в чем же его достоинства все-таки?
Не работаю с flask плотно, но отличия, на мой взгляд очевидны — он менее «связный». Django предоставляет хорошую основу для сайтостроительства, но он монолитен и смена какого-либо компонента может быть сопряжена несовместимостью с батарейками и вызывать глюки в ядре. Flask-же обезжирен по максимуму. А много расширений подгоняющие flask под django — это хорошо, есть из чего выбрать :)
Я Фласк активно сейчас не юзаю, и не могу сказать что освоил его вдоль и поперек, но несколько проектов на нем сделал. Для совсем небольших проектов, которые умещаются в один файл, удобно тем что можно действительно обойтись одним файлом, а у джанги будет целая куча файлов даже для hello world. А вот когда проект становиться большим, то у него уже появляется структура и он постепенно превращяется в Джангу, правда своеобразную Джангу, без батареек. Батарейки во фласке безусловно есть, но количества сравнимого с Джангой нету. Я сделал два проекта на Фласке, а когда они немного подрасли, плюнул и переписал на Джангу. Слишком много приходится писать велосипедов, которые в Джанге есть готовые.
Jinja2 прикольная и мне понравилась, но написание кастомных тэгов меня ужаснуло. Тут я тоже и итоге предпочел джанговские шаблоны, местами шаблоны конечно не так удобны, зато кастомные тэги пишутся на раз-два.
пишу на Flask. Он очень гибкий. Захотелось вместо SQLAlchemy выбрать peewee — используй, никто не против. Вместо Jinja2 захотелось Jade — пожалуйста. Хватает 1 файла? Пиши в нём. Хочешь дорасти до django — расти. Но не думаю, что кто-то пытается сделать из него django, или как-то противопоставляет их. Просто пишется нужный функционал, не удивительно, что он уже может быть реализован в django ранее.
В нём всё прозрачно. Нет никакой «магии».
Ну и чисто субъективно. Мне очень нравится маппить урлы декоратором @app.route("/services/", methods=["GET","POST"]) в файле с вьюхами, чем в отдельном urls.py писать:

urlpatterns = [ url(r'^services/$', views.services_list_view), ... ]
А вот мне как раз чертовски не нравится такой подход к маппингу урлов. Чтобы найти, какая вьюха обрабатывает "/services/", надо все файлы, содержащие вьюхи, вручную перерыть.
Это для больших проектов справедливо, а когда на весь проект два-три файла с вьюхами — достаточно удобно.
Ну и можно в app.url_map._rules посмотреть, чтобы совсем руками не рыть.
Добавлю немного актуальности:
@async
def send_async_email(app, msg):
    with app.app_context():
        mail.send(msg)

Sign up to leave a comment.

Articles