Артур Кузнецов

Библиотека это инструмент или набор каких-то инструментов.
Бибилиотека для скачивания видео с ютуба
Бибилиотека для кропа и ресайза картинок
Бибилиотека для определения города по IP

Фреймворк может использовать десятки или сотни разных библиотек. Это набор не только инструментов, но и готовых компонентов, и еще и рекомендация по их использованию.

"набор для постройки скворечника"
В комплекте молоток, гвозди, столярный клей, 20 деревянных досточек разных форм и расцветок и инструкция с тремая вариантами скворечника на выбор.

Или вот два фреймворка:

Можно ли их использовать вместе? (Конечно, никто не запрещает)
Можно ли из этих деталей построить что-то совсем другое, не такое как в инструкции? (Конечно да)
Можно ли с этими фреймворками использовать детали еще и из этого?

(конечно можно, но придется что-то придумать для совместимости деталек. Быть может придется применить клей, изоленту, пластилин или жвачку. Или шуруповерт, или сварочный аппарат. Но ни в один комплект эти дополнительные инструменты не входят, как и скиллы к ним.)

Можете посмотреть еще сюда, этот ответ частично покрывает ваш вопрос:
Для чего нужны фреймворки, а-ля Laravel?

Как правильно релизиться в больших компаниях?

То что ты описал указывает на слабое планирование. Должен быть менеджер проекта который организует процесс планирования в котором будет участвовать Продакт Овнер, Тимлиды всех групп и он сам. Результатом планирования должна получится диаграмма ганта или Roadmap в котором будут учитываться взаимосвязи и будут заложены адекватные риски. Я это делаю всегда, и у меня на проектах почти никогда не бывает таких вот блокеров как ты описываешь.

По поводу релизиться есть разные методики.
Версионность это хорошо если вы работаете через API, а если у вас несколько команд бекенда которые пилят один и тот же монолит то нужно внедрять практику GitFlow и ставить техлида который будет заниматься мержами веток в релизы и правильно построит адекватный GitFlow.

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

Что бы релизы проходили плавно нужно погрузить себя в книжки по Continues Delivery и занятся докеризацией своих сервисов или монолита.

Существует понятие цикла релизов. Каждый цикл подразумевает детерменированное количество изменений внесенных в продукт.
Для каждого релиза объявляется набор интерфейсов между компонентами. В разных проектах это реализуется по-разному, например в веб используются инструменты вроде Swagger.
Есть архитектор, который отвечает за общий интерфейс. Он объявляет версию, например 1.0.5. Бэкенд и фронт-энд пилятся под соответствующую версию интерфейса. Если одна команда не успевает, происходит релиз 1.0.4, т.е. то, что готово или релиз откладывается.
Обычно может быть объявлено несколько версий интерфейса.
В больших и сложных проектах используется модульный подход. Каждая команда отвечает за свой компонент проекта и имеется координатор проекта. Он отвечает за релиз. В любом случае подготовленный релиз проходит через команду тестировщиков и т.д. Просто так сырой код в продакшен не попадает.

1. Фича-тим это хороший инструмент менеджера, для синхронизации технических решений и соответственно снижения рисков. В одновременные релизы разных команд я не верю.

2. С "версионностью" мне кажется не так много сложностей на самом деле.
Если воспринимать результат работы каждой команды как какой-то сервис с api наружу (а так наверное и есть), то по сути от команд требуется обеспечивать обратную совместимость новых версий api со старыми - задача которая в любом случае полезна.
Делать версионность без обратной совместимости - очень плохая идея как мне кажется. Тут и затраты на поддержку, и затраты на переподключение у всех остальных команд.

Еще очень важно, чтобы был вменяемый CTO / архитектор всего этого зоопарка. Ну или хотя бы просто был.

Видел живые проекты где не было продумано общей архитектуры, - поверх слоя основных сервисов по бизнес требованиям писался 2й слой, через годик поверх 2го слоя писался 3й, ... в итоге к нашей эре слоев было ~12 и как это точно работает не знал мне кажется никто, - что впрочем не мешало проекту иметь десятки миллионов пользователей.

Следует начать с проектирования API. Возмите https://swagger.io/ и набросайте все, что нужно.
Swagger вам позволяет объединить роутинг, документацию и примеры вызовов в единое целое.
Кроме этого он позволяет сгенерировать заглушки для разных языков программирования и фреймворков.
В принципе вы можете найти значительное количество интеграций для разных фреймоворков.

В целом API лучше делать с помощью фреймворков, поскольку в них уже реализованы тривиальные моменты по безопасности, аутентификации и авторизации. Вы можете использовать микрофреймворки, например тот же Slim. Вы даже можете сгенерировать роутинг для него используя генератор от Swagger.

В REST есть 6 принципов, прекрасно изложенных в Wiki. В REST нет ничего сложного и особенного. Это просто надстройка над стандартным протоколом HTTP. Именно поэтому нет никаких особенных уроков. Изучите работу HTTP и вы поймете как работает веб в целом и REST в частности.

По поводу отдельного сервера для API. Есть множество разных подходов. В последнее время все более актуальными становятся Serverless-приложения. Serverless архитектура идеально вписывается в REST. Но думаю для вас это пока рановато и сложновато. Слишком много для начала.

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

По поводу best practices есть очень хороший ресурс https://12factor.net/ru/
Он в целом применяется для всех приложений.

Запомните: первый блин всегда комом. Прочитайте все ресурсы, которые я привел для вас. В них много ссылок на другие, походите по ним, присмотритесь. Напишите первую версию API так, как вам кажется удобно. Постарайтесь применить практики из статей.
Вам нужен опыт и вы его не наберетесь, пока не сделаете что-то сами. Вы можете потратить год на чтение, но останетесь на том же месте, с которого начали. А другой человек напишет на коленке API за неделю, а потом перепишет его 20 раз за год и он вам расскажет в 10 раз больше, чем то, что вы изучили за год.
Дерзайте!