Robur

request-promise обертка над request, у которого есть работа с прокси
https://github.com/request/request#proxies

Вашему фронтендщику стоит посоветовать сначала изучить как это делается а потом огород городить.
но судя по тому что вы вместо него это выясняете, его все устраивает а вас - нет.

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

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

Нормально так:
Кнопка для логина - одна.
запрос аутентификации - один.
сервер отвечает ошибкой или успешным ответом. Сама сессия ставится кукой, эта кука по хорошему должна быть httpOnly и из js кода не доступна. С ней работает исключительно бэкенд и так как хочет.
Аппа из ответа сервера (в body) либо сделав отдельный запрос (типа /currentUser) понимает что это за пользователь - менеджер или обычный и сохраняет это куда-то себе. В случае реакта это с большой вероятностью стор. Можно в localStorage чтобы при перезагрузке читать сразу оттуда.

Дальше аппа просто смотрит в стор в нужные моменты чтобы понять что пользователю показывать что нет.
Все права на запросы бекенд разруливает на основе сессионной куки которая приходит с каждым запросом автоматически. То есть сессии как таковой фронт вообще никак не касается - его дело - вызывать login/logout, получить от бэка инфу о текущем юзере и правильно обрабатывать 401.

Можно сделать и более сложные варианты - без куки, с каким-нибудь токенами и прочим, но скорее всего вашему фронтэндщику еще рано.

a.addEventListener('click', function () {
	setTimeout(() => history.replaceState({}, '', locationWithoutHash))
})

после этого ссылка при наведении мыши вместо http://site.ru/#portfolio покажет http://site.ru/portfolio#portfolio но с этим можно жить (и даже нужно чтобы анкоры продолжали работать), зато страница проскроллится куда вам надо и в адресной строке будет http://site.ru/portfolio

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

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

Так же есть разные методологии и подходы, например не разделение на фронт и бек команды а разделение на фича-команды. Когда одна команда пилит сразу и фронт и бек и что там еще нужно чтобы выкатить фичу в релиз.

Варианта по большому счету два - линукс и мак. Виндовс не берем - можно но заметную часть своего времени вы будете тратить на внезапные проблемы которых без винды у вас бы не было.
И то и то подходит хорошо, мак лучше тем что можно собирать приложения под ios, линукс лучше тем что за те же деньги вы купите заметно мощнее комп и разработка будет приятнее.

Можно и так, можно и в reducer, или actions. Действия с данными делать надо там где это уместно, а уместность зависит от того что именно вы делаете.

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

Можно.
Apollo в своем кэше может хранить все данные приложения относящиеся к серверу (фактически это все кроме состояния UI и еще пары мелочей типа сессии пользователя)

Так что в mobx просто становится меньше смысла, но совсем он не пропадает - если вам нужно зачем-то шарить состояние компонент друг между другом.

Ребята в Apollo предлагают его же использовать как стор и обращаться к локальному состоянию с помощью gql так же как и к удаленным данным. Не уверен насколько такой подход реально удобен в работе с состоянием компонентов, но возможность добавить какие-то локальные свойства к данным весьма неплоха.
вот тут можно почитать: https://www.apollographql.com/docs/react/essential...

То что разные программисты в одном проекте писали одинаково - это признак хорошего проекта и хороших программистов. Или в проекте было такое принято явно, тогда это соглашение для проекта или так сложилось и это просто не меняют.

"вообще" соглашения такого нет, да и вообще каких-то общих практик за пределами рекомендованного в доках довольно мало.

вам поможет https://reactjs.org/docs/react-component.html#stat...
но на самом деле вам нужно использовать props напрямую, в state хранить только то что может поменяться в процессе работы самого компонента при неизменных пропсах

Законно, по крайней мере пока еще не запретили, но возможно мы к этому когда-нибудь придем.
Храните как вам удобно - интерфейсы бывают разные, если это вообще глобальные - то в один файл в корне, но таких на самом деле обычно мало и больше тайп-конвертеры.
Чаще всего интерфейсы описывают какие-то сущности, кладите их туда же где и код который отвечает за эти сущности.
Например если у вас есть стор и в нем какие-то данные описанные интерфейсами - кладите рядом с данными и экспортируйте оттуда.
Если есть апи которое возвращает данные и для этих данных есть интерфейсы - кладите рядом с апи. И так далее.
Можно прямо в файлах с логикой, можно рядом в файле чисто с интерфейсами. Мне удобнее все в одном - так как если что-то меняется в интерфейсе то обычно меняется вместе с логикой.

так же как и vue.
подключаете js в котором инициализация реакт - приложения в нужный контейнер.
Данные туда можно передавать по разному, я бы просто в js положил в глобальный объект какой-то.

Лучше тогда верстальщиком фронтенда, на письмах вы только в письмах и будете разбираться. а верстая нормальный проект - можно будет смотреть чужой код, учиться, спрашивать коллег и самой что-то пробовать добавить помимо верстки, со временем брать задачки, попроще, потом посложнее, потом еще сложнее, а потом глядишь и вас уже фронтендером возьмут.

Если вы поставите маску /32 - у вас там будет только один хост в сети а надо минимум 3 - ваш сервер, роутер, и broadcast. Так что сеть может быть как максимум /30. И хостеру придется для каждого пользователя такую сеть создавать и в каждую выставлять роутер по дефолту.
При публичных IP смысла в этом нет - вы все равно будете способны их точно так же пропинговать, ровно как и любой другой адрес в интернет, зато адреса расходуются впустую.