PR
Задачу для начала надо определить.
кнопка "сделать зашибись"
Size: a a a
2019 November 12
KP
кнопка "сделать зашибись"
Тогда и джанги мало
PR
Тогда и джанги мало
но рельсы уже ничего
D
CBV - это идеологически не очень хорошо
А как наследовать от базовых? Как разные action в одной view выполнять, кучей if request.POST?
KP
Странно
Почему же? Django это all-in-one, которые имеет много всякой магии под капотом. Чего только мета-классы стоят.
KP
но рельсы уже ничего
Да, согласен. С этой постановкой рельсы справятся получше. Хоть я их и не люблю.
AO
про Django - современный подход https://phalt.github.io/django-api-domains/
AO
(приложения как аналог микросервисов, DDD)
KP
А как наследовать от базовых? Как разные action в одной view выполнять, кучей if request.POST?
А зачем наследовать от базовых? Если там есть общее поведение, то это либо уровень middleware, либо декоратор.
PR
Почему же? Django это all-in-one, которые имеет много всякой магии под капотом. Чего только мета-классы стоят.
джанго прекрасен ровно до того момента, как надо копнуть вглубь. как только уходишь ниже уровня воды - начинается ад
AO
А как наследовать от базовых? Как разные action в одной view выполнять, кучей if request.POST?
это не очень хорошая идея, разные action'ы объединять во что-то одно, как мне кажется
AO
лучше идти в сторону serverless FaaS, каждый метод как отдельная сущность
AO
мб под одной схемой API, а в остальном функция независима от других
KP
лучше идти в сторону serverless FaaS, каждый метод как отдельная сущность
А теперь посмотрим на накладные расходы на передачу данных между serverless функциями, скорость запуска, подгрузки ресурсов. В общем, не универсальное это решение...
KP
Так точнее
AO
вообще, современная архитектура - это комбинация функций и микросервисов [на Go c gRPC зачастую]
AO
ну, обычно
AO
иногда есть исключения - тот же Instagram, они писали на Medium'е статью
AO
там вот как раз Django с FVB и декораторами
AO
они там описывали про декораторы, как они это сделали