Максим Федоров

Яндекс.Практикум, есть друзья там, кто обучается — очень крутой подход с преподами, курсовыми, экзаменами и всем этим...
Учат работать с юзкейсами, тестирвоание гипотез, интервью заказчиков и, конечно, техника и навыки...

Школа Дизайнеров от Бюро Горбунова — очень крутые ребята, их хантят на выпуске топовые компании
вот дипломы https://bureau.ru/school/projects/
Тут не только техника дизайна, но и глубокая работа редакторов по работе со смыслом для пользователя. Работа с текстом (под патронажем Максима Ильяхова (автор "Пиши сокращай")

Docker очень удобен и прост для поднятия каких угодно сервисов для нужд проекта...
RabbitMQ, базы для дева/теста, какие угодно демоны и прочее... супер-просто и супер-надежно

Статьи про ненужность Докера идут только в контексте контейнеров на проде в кубере и прочее

если, например мне нужно запустить 3 сайта. api.domain.loc, lk.domain.loc, domain.loc. Как сделать, чтобы в адресной строке браузера указывать эти домены и попадать на каждый проект?

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

Итого:

• Создаете в docker-compose некоторую сеть (секция network в docker-compose.yml, у каждого из сервиса делаете expose 80 порта (не биндинг портов, чтобы конфликта в localhost не было)
  
• Ставите реверс-прокси с nginx, чтобы он тоже мог с этой сетью работать
  
• Настраиваете его так, чтобы роуты он направлял в нужные сети нужным серисам
  
• Все домены добавляется в /etc/hosts
  

Хороший совет

Node JS обычно ставится за Nginx (веб-сервер) и запросы, которые не статич файлы (картинки, иконки, стили), проксируются ноде, а сами файлы самим сервером Nginx

Плохой совет

но если очень хотите, то так (там есть вариант для ванилы как у вас):
expressjs.com/en/resources/middleware/serve-favico...

Каждый запрос просто делайте с заголвоком Bearer: b43hb54b64bv46v46v464bmkkm
Сервер прочитает, если нет токена, то 401 и отправить на страницу входа
На входе получаете токен и сохраняете локально в localStorage, потом на каждом запросе к бекенду добавляете этот токен

Такая типовая практика

пишу все сам без фреймворка

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

Начинаем с границ
Очерчиваем границы нашей системы, как-будто у нас есть этот "идеальный заказ".
Это будут интерфейсы некоторых абстрактных реквестов и респонсов.
Реквест на обновление, добавление и респонс на получение и т.д.... И несколько ДТО их реализующие или которые и будут этим интерфейсом сами по себе.

Далее вы строите клиент OrderClientInterface, который выше созданные реквесты отправляет, респонсы возвращает. И на его интерфейс вы завязываетесь. Строите поверх него фабрику, которая построит вам нужный клиент под нужную систему :)

Адаптеры (к слову это и паттерн одноименный)
Клиенты-адаптеры уже будут связывать АПИ внешних систем с интерфейсом вашего абстрактного (имеется в виду интерфейс) клиента. Через guzzle, или через некий свой sdk, уже для вашего домена не важно, дело техники. С авторизацией или без нее... Это детали клиента.

Это довольно общая рекомендация, но стоящая и очень упростит вам работу. Несколько интерфейсов, несколько дто, фабрика и остальное дело техники, просто и надежно

Бизнес-логика
Теперь пишите хэндлеры в вашей бизнес-логикек: из контроллера, демона, команды вызываете нужные хэндлеры и строите запросы. Саму обработку их результата и контроль состояния делаете в сущностях.
Ну я так понимаю, вопрос касался адаптеров.

какой смысл использовать Apachе или Nginx содержащий образ? Разве нельзя работать с контейнером содержащим только php?

Разве нельзя работать с контейнером содержащим только php?

Можете. Вы можете поставить PHP-CLI контейнер и работать с ним без веб-сервера конечно же
FROM php:7.1-cli
Что позволит вам запускать консольные команды (композер туда же)

Если ставите PHP-FPM контейнер, то понятное дело вам нужен веб-сервер (гуглите принцип работы с Fast CGI).
Нужен, если вы хотите общаться с приложением через HTTP
FROM php:7.1-fpm

Думаю не стоит задавать вопрос, выпятив в первой строке: "уже пару лет работаю senior full-stack", тк в принципе об этом не стоит писать (отдает тщеславием) и далее читая содержание вопроса — оно не коррелирует с тем, что вы написали в первом предложении, тк именно сеньоры и подсказывают, как и что делать.
Крч всем пофигу на ваши достижения, и так помогли бы, но помогать сеньору — оксюморон получается...

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

Если тимлидерство выберете — вам путь к менеджменту, руководству, управлению и вот этому всему.

Кроме того по обоим направлениям вы можете рассказывать о своих достижениях или своей команды на конференциях, семинарах. (Например Highload/fwdays, phprussia, badoo митапы)

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

В разных компаниях делают по-разном, где-то юзают маркдаун, где-то контент-билдер, который перетягиванием как конструктор собирает статью, но есть вот такой вариант:
https://editorjs.io/

Попробовать в-живую: https://vc.ru/writing

Сделан одни издательством (vc.ru, TJournal) -- редактор просто позволяет накидывать разные сущности статьи, на выходе JSON, который вы можете трансформировать в разные блоки... В документации почитаете, как расширить словарь этих сущностей.

У меня в блоге например некий подвариант маркдауна, вставляешь 2 картинки -- парсер видит соседство и генерирует код слайдера, если отдельно -- парсер генерирует 2 тега img со своими атрибутами. Блог -- обычная CMS, сделан Ильей Бирманом

Способы транспорта (сходу) :

1. API на одной стороне в любом формате (json, xml, csv), и сборщик с другой стороны, который по крону к этому API обращается и забирает новые/все данные. В случае большого числа данных -- делать ограниченными порциями.
   
2. брокер сообщений, то есть одна система при добавлении/изменении данных генерирует событие, которое пишется в брокер сообщений, который слушает другое приложение и данные забирает себе по каждому сообщению. В случае нагрузки в общем случае ничего не нужно особо делать, тк транспорт идет единичными порциями и сразу, если работает демон реалтайм
   
3. все пишется в таблицы одной бд, одно пишет, другое читает
   

OAuth 2.0 Server
язык PHP

Город по IP-адресу

Сделай сервис определения города, который и будет к АПИ обращаться просто через CURL или Guzzle
Сделай простой контроллер, к которому из фронта будешь цепляться по аяксу, и значение в сессии держи

Если проект на php, то прекрасно подойдёт Deployer (на php, парень из Aviasalrs написал) , использую его в разработке, где я один разработчик (и на работе в достаточно сложном CI тоже его используем)

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

Если что -- пиши вопросы в лк