AM
Говорим, как и куда декомпозировать задачи.
Size: a a a
2019 May 06
AO
да, вот это вот
AO
просто в Django принято делать это в методах моделей и менеджерах
AO
а тут "какие-то сервисы ещё придумали"
AO
мне кажется важным объяснить, что как отдельные сервисы - это круче
AO
вот именно тут больше всего непонимания
AM
dry-python он framework agnostic. И одинаково выглядит с django, flask и aiohttp.
Писать логику в методы моделек и мэнеджеров не очень хорошо с прицелом на будущее. 100% появятся 2 God Object. Моделька User и моделька того чем занято твоё приложение. Например, модель Order.
Писать логику в методы моделек и мэнеджеров не очень хорошо с прицелом на будущее. 100% появятся 2 God Object. Моделька User и моделька того чем занято твоё приложение. Например, модель Order.
AL
Не вопрос. Мы командой dry-python наверное можем собрать стрим, поотвечать на вопросы. Может даже лайф кодинг организовать.
было бы очень круто! смотрел ваши даклады, но мало, стрим или что-то в этом духе — самое то
AM
Тут же получится ясный и понятный слой сервисов. Где не все возможные методы перемешаны в одном классе, а грамотно разбито по сценариям использования твоего приложения.
MA
Интересно было бы посмотреть на реальные примеры. Я вот с трудом себе представляю DDD с Django.
MA
Я один раз пробовал, два месяца просидел, взял алхимию и фласк вместо Django, чтобы гибче было. Итог - куча однотипной копипасты, которую я в итоге за одни выходные переписал на Django. Ну, может проект неудачный был. :)
VD
MM
камрады, как в продакшене вы запускаете приложения в докере? (если такое делаете)?
я через гуникорн запускаю, работает нормально, но вот с заменой контейнера на более новую версию возникают непонятки, приходится сначала прибивать вручную, а затем запускать новый контейнер, что некошерно
я через гуникорн запускаю, работает нормально, но вот с заменой контейнера на более новую версию возникают непонятки, приходится сначала прибивать вручную, а затем запускать новый контейнер, что некошерно
Этой работой пусть оркестратор занимается. Он же будет поднимать упавшие контейнеры, например. Мы сейчас используем Nomad, раньше был Rancher (очень простой, но глючноват), ещё есть Kubernetes, Mesos
MM
И да, у нас nginx перед gunicorn, пока нагрузок нет что-то более заморочное делать
RP
Этой работой пусть оркестратор занимается. Он же будет поднимать упавшие контейнеры, например. Мы сейчас используем Nomad, раньше был Rancher (очень простой, но глючноват), ещё есть Kubernetes, Mesos
Вопрос был про другое, как правильно организовать контейнер, чтобы он нормально в шатдаун уходил
MM
Вопрос был про другое, как правильно организовать контейнер, чтобы он нормально в шатдаун уходил
Не, вопрос был именно про это. Поднимать контейнеры руками, конечно, бред, для этого и нужен оркестратор
AM
что в данном примере бы хотелось: добавьте второе приложение и покажите, как они друг с другом взаимодействуют
Я только за. Можешь как-нибудь описать сценарий этого взаимодействия, чтобы я мог реализовать.
AM
и что ещё бы хотелось - вот эти примеры с шаблонами и формами - ну, это прикольно, но выглядит слегка устаревшим, интересует API (разных видов, GraphQL, RESTful, gRPC, возможно)
Апишку добавим, да.
AM
я не до конца понял, вот есть второе приложение такое же рядом
Подробнее. Это в тему взаимодействия.
V💊
вау, всё чаще в таких чатиках встречаются медийные люди