Виталий

1. чаты делятся на комнаты, реализуешь протокол, можно типо ирц. Например есть на сервере подписка request:join
Когда твой клиент решает войти в определенный чат, он делает отправку запроса на сервер emit('request:join', roomName); на сервере есть реакция, обработка можно ли клиенту присоединиться к этому чату или нельзя.
2. в обработке события на сервере у тебя идет on('request.join', roomName=>socket.join(roomName); В этот момент надо перебрать все активные сокеты, на предмет того, используется ли клиентом второе окно (если это требуется конечно).
3. По этому принципу можно строить и общие чаты, и приватные. Люди начинают общаться не друг с другом, а писать в канал. клиент пишет emit('message:send", {room: id, message}), на сервере это пересылается в рум как .on('message:send', message=> io.to(message.room).emit(message.message)
В результате получается что клиенты общаются между собой, но по факту лишь шлют все данные своему серверу, а он уже принимает решение уведомить об этом остальных или нет.

на мой взгляд и gql может быть тоже использован в простых запросах.
по мне не надо циклиться на уровне моделей, так как это концепция простых и не сильно зависящих друг от друга данных. мы называем эндпоинт именем таблицы и методом запроса определяем что мы с этим делаем, это же уровень блога или списка новостей.
а как быть , когда при обращении к 1 эндпоинту выполняется запрос к бд на 100 строк? какой там gql ? все эти упрощения для обычных и ежедневных задач, если требуется выполнять нетривиальные действия, то нужно планировать свою концепцию апи и забивать на ограничивающие тебя рекомендации.
например /api/сущность/действие
Зачем вообще задумываться как на твою объективно нужную классификацию апи наименования посмотрят другие? у тебя есть задача, ты ее решаешь и все.

странный вопрос, если он задан правильно, то вопрос о том как передавать данные в дочерние компоненты, ответ очевиден - props
если стоит задача передать из одного компонента в другой (когда ни один из компонентов не является родителем или дочерним), то их можно обернуть в один компонент, отдающий компонент должен иметь колбек функцию из серии stateOnChanged , в родителе это изменение фиксируется в стейте, на который подписан принимающий компонент, дальше данные перебегают так же через пропс.

Если дело только в фетч , достаточно сделать полиыил фетч

Я использую драйвер с сайта производителя. Минусы ставить надо из консольного режима, переустановка руками с каждым ядром. Поставь их попробуй, можно отложить в сторону Хорн.конф у меня были проблемы с ним из-за запуска нвидиаконфиг. При старте х организации его создаст автоматом.

уважаемый автор, вы получили адекватное предложение на вашу задачу.
чтобы получить предложение с фиксом, от вас должно быть тз, чтобы программист смог просчитать какие работы ему надо выполнить, перемножить ставку часа на количество часов, помножить на коэффициент непредвиденных задач, если таковые допускаются на старте сделки, далее предложить вам ценник услуги. Ни один опытный исполнитель не будет себя обманывать и на задачу, которая выглядит как фикс прайс всегда заложит гарантированно больше часов чем ему потребуется.
в вашем случае в теме нет задачи, которую можно было бы измерить в человекочасах, потому вы получили адекватное предложение от разработчика.
и судя по вашей реакции с вами очень рискованно иметь дело, вместо формирования тз вы выкинули тему на треп, чтобы специалисты подтвердили правоту вашего мнения. Увы здесь вы ошиблись.

Резольв без ретурн, вместо фроу реджект, в него Нью эррор
Гетбоди писать без асинк, ты возвращаешь промис из обычной функции

что-то такое

Если связь 1 к 1 то можно ид группы цеплять полем к юзеру, если групп может больше чем 1 то через отдельную таблицу связей где будет юзер 1 группа 1 юзер 1 группа 2

Изучи документацию к модулю отправки запросов, укажи там прокси сервер и все

const query = {...location.query}; // фигня ж , попробуй такое в консоли сделай
const {query} = location;

const sort_direction = location.query.sort_direction ? location.query.sort_direction : pageContents.books.default_sort[activeList];

метеор мне понравился , но его заточенность под монго не совсем привлекла, вроде как есть кастылизация под другие бд, но мне не по душе орм
по тому мой выбор koa.js jwt socket.io pg-promise (бек), постгрес как бд, на фронт два варианта реакт / реакт редакс либо через CRA с eject конфигурации и ее коррекцией с последующим проксированием через нгинкс либо если требуется SSR то подключение next.js.
В любом случае каркас проекта и требования к тому что пишут разрабы нужно устанавливать сразу, но если проект без особых заморочек, не думаю что это проблемой может быть.

все зависит от стратегии в каком ты рынке
если ты клепаешь быстрые проекты и знаешь точные сроки по их воспроизводству, то время на работу тебе известно, дальше плюсуй в эту стоимость время, которое ты тратишь на косвенные работы, согласование с заказчиком. переговоры с потенциальными заказчиками, поиск проектов. Упаковывай это в коробку и продавай.
Если задание более серьезное, считай стоимость от технического задания, чем оно более плавающее, тем менее точные диапазоны ты можешь дать. Потому прицелившись и на глазок оценив стоимость таких работ ты легко можешь попасть в просак. Так что тут лучше просто сойтись на контракт по часам. Стоимость часа по рынку тоже достаточно не сложно выявляется.
Дмитрий красиво озвучил два вопроса заказчика, видимо он только с хорошими заказчиками имеет дело. Есть и не такой тип заказчика, а потому любое тз, которое дробит сумму по подзадачам может стать поводом заказчику под приземлить проект, скажем упростив его части, и тут нужно быть точно уверенным, что упрощение будет. как то так. А вообще, только опыт даст правильный путь.