Почему не нужно разделять фронтенд и бэкенд
Основная проблема отдельных репозиториев – согласование API и синхронизация фич.
Единственный надёжный вариант определить, что фронтенд из бранча feature/x работает с бэкендом из бранча feature/y, – делать API обратно-совместимым. Без обратной совместимости не получится и релизить, так как релиз API должен гарантированно работать с любой версией фротенда.
При правильном CI, каждая фича должна пройти QA перед тем, как попасть в master. Чтобы задеплоить фичу на стейджинг, нужно собрать и задеплоить два разных бранча из двух разных репозиториев. Это делает деплой нетривиальной задачей и/или заставляет придумывать правила о том, как называть бранчи и так далее.
У нас один репозиторий для проекта на 5 разработчиков. Мы осознанно пришли к этому от двух отдельных. Не исключаю, что когда-нибудь вернёмся к разным репозиториям, но пока это преждевременная оптимизация, создающая только бесполезный оверхэд в виде обратной совместимости API и танцев с деплоем.
Основная проблема отдельных репозиториев – согласование API и синхронизация фич.
Единственный надёжный вариант определить, что фронтенд из бранча feature/x работает с бэкендом из бранча feature/y, – делать API обратно-совместимым. Без обратной совместимости не получится и релизить, так как релиз API должен гарантированно работать с любой версией фротенда.
При правильном CI, каждая фича должна пройти QA перед тем, как попасть в master. Чтобы задеплоить фичу на стейджинг, нужно собрать и задеплоить два разных бранча из двух разных репозиториев. Это делает деплой нетривиальной задачей и/или заставляет придумывать правила о том, как называть бранчи и так далее.
У нас один репозиторий для проекта на 5 разработчиков. Мы осознанно пришли к этому от двух отдельных. Не исключаю, что когда-нибудь вернёмся к разным репозиториям, но пока это преждевременная оптимизация, создающая только бесполезный оверхэд в виде обратной совместимости API и танцев с деплоем.