@lorddaedra можно я тебе еще тут вопросы про DDD позадаю?)
курю доки сейчас и на этапе "добавляем rest/graphql" у меня интересная дилема возникла, рекомендуется отказаться от магический джынго/алхимия типов и описывать все модели ручками 2+ раза, саму модель и гкл/рест вьюху, а если и гкл и рест то это уже 3 раза описываешь почти одно и тоже.
а в случае с фастАпи вообще 4 раза, моделька, моделька для алхимии, моделька для графкл, моделька для реста.

вопрос, это нормально?) а то мне кажется что это очнь близко к нарушению DRY ;(

graphql, наверное, лучше сверху над микросервисами делать

если в этом есть потребность

о а давайте это в другом чате ;)

потребность есть если упирается в коммуникации между фронтендерами и бекендерами

почему? тема связана с Django

точно ?

Django - это же фреймворк, а не CMS

да, вопрос изначально по джанге

тогда сорри

смотри, ты написал про GraphQL, когда он нужен? когда у тебя есть js/iOS/Android разработчик и джангист и они задолбались коммуницировать друг с другом на тему "плиз, сделай мне вот ещё один API для выборки данных"

типа пилим какой-то api gateway который с микросервисами общается по gRPC допустим, и на этом gateway мы пилим графкуэль, которая уже делает запосы с помоью grpc?

да

GraphQL это как "SQL для микросервисов"

если тебе такое нужно (для аналитики или для упрощения работы фронтендера), тогда ставишь

если не нужно, то не ставишь

что ещё? ну, модели джанги тебе нужны чтобы привязать структуру таблиц к джанге (или наоборот, модели к базе)

то есть модели точно будут иначе зачем тебе джанга

ну, как бонус получаешь то, что они быстрее аналогов

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