mr_drinkens

Ну, вариант что в трелло подобных проектах NoSql полезней - спору нет.
А вы не думали над тем, чтобы перенести всё на монгу? Ну типа, ОРМ вы больше использовать не сможете из джанго) Но зато прирост в том, что не нужно делать вложенные запросы. Монго позволяет хранить вложенные документы и структуры.

По надежности монга - такой же good guy с масштабируемостью, как у постгре. Просто тут диллема: или парится с несколькими запросами в постгре, или парится с миграцией в монгу и делать запросы уже там.
Плюс фишкой джанги есть ОРМ, а официально есть ОРМ только для sql баз

Идея так себе.
Надо взвесить все + и -
Самый жирный и весомый "-" это то, что либо придется дублировать данные что бы была возможность работать со всеми возможными (в т.ч. теми, которые появятся потом) требованиями по запросу данных из бд, а тут сложность синхронизации и риск рассинхрона. Либо делать joinы в коде, что тот еще костыль.

Если нужно взаимодействие только в одну сторону (сервер->клиент), то можно возложить эту задачу на отдельный сервис на nodejs.

Сокеты. Long Polling для синхронной джанги так себе вообще. А channels отлично встраивается рядом с синхронными вьюхами.

Это философский вопрос. Если человек адекватный, пусть и не технарь, можно попытаться спокойно объяснить. Если человек неадекватный, то никакие объяснения не помогут, не надо даже пытаться, все равно будут сплошные проблемы. Он пойдет на какую-нибудь фриланс-биржу, там найдет «разработчика бэкенда с огромным опытом», который пообещает сделать ему бэкенд за 3 дня и 1500 рублей. Будет делать три месяца, в итоге выкатит неработающий ужасный код, потом другой разработчик будет 6 месяцев пытаться привести это в работающее состояние, тем временем заказчик, возможно, осознает свою ошибку и станет чуточку умнее. Или не станет.

Показать что находится под капотом автомобиля.
И показать, что "просто повернуть ключ зажигания" требует взаимодействия около 4 различных систем - "микросхема = аккумулятор = стартер = бензонасос = инжектор = двигатель". А ты всего лишь ключ повернул.

Если человек упертый на свой волне - поверь, никак.
Это как с друзьями, которые узнают, что ты умеешь делать сайтики, а потом предлагают свои великие бизнесс планы по захвату мира на ххх часов рабочего времени. Ты им говоришь, обьясняешь что да как, обьясняешь вообще всю суть разработки. А в ответ слышишь вбросы, по типу:
- да что там делать? Это же пару кнопочек нарисовать.
- Молчание... Так и скажи, что не умеешь! :D

Но что я усвоил: Никогда не пытайся гуманитарию обьяснять техническую часть. Если он уверен в своей правоте и легкости задачи.
Представь, что перед тобой ребенок и ты пытаешься ему обьяснить на пальцах, примерах из жизни и желательно близких для него. Узнай кто он по специальности и попробуй приводить аналогии из его области в полной абстракции.
Если не узнавать кто он и вообще шарит ли он в чем-то, то можно взять что-то нейтральное. Например "машины", хотя и тут может оказаться, что он просто потребитель и кроме двух педалей больше ничем не интерисовался)

"Бэкенд получает данные из Базы, обрабатывает под нужные задачи и отдаёт их на Фронт". Мне хватало)

Если разговор доходит до "почему так долго?" можно сесть и подробненько, с терминологией, рассказать заказчику, что вы делаете. Поймёт - хорошо, не поймёт - испугается терминов

Попробуй найти/написать какой-нибудь код на несколько страниц и попытайся рассказать какие функции и зачем он выполняет, т.е. объясни на конкретном примере другого проекта

Главное в каждом предложении вставлять слова "сервер" и "базы данных" и он сам от вас отстанет.

create-react-app

правда итоговый файл все равно не маленький и несколько сот килобайт приближаются к 500, но это еще и от проекта зависит ...

От ситуации зависит.
Был компонент, который зависел от своих же данных - использовал state.
Но потом понадобилось добавить второй и чтобы они были синхронизированы - вот тут пришлось использовать store приложения.

Через state и делайте. То, что не нужно никаким другим вашим компонентам (которые, вдобавок, не являются потомками) отлично уживается в state.

Нет

Трогать $rootScope не очень прально, как вариант сделать как то так

.factory('faqSocket', function($websocket,$rootScope) {
         var factory = {}
          var dataStream = $websocket('wss://api.myserver.com/faq/');
          dataStream.onMessage(function(message) {
            $rootScope.$apply(function () {
                factory.answer = message['data'];
          });

          factory.dataStream = dataStream ;

          return factory;
})

В самой директиве или выводите данные на прямую с фабрики или ставите вачера на переменную factory.answer