Ссылаюсь больше на сервис-ориентированную архитектуру, где отдельная часть (выделенная согласно подцелям бизнеса, а не технологически) является в большей степени независимой как на серверной стороне, так и на клиентской.
В микросервисной архитектуре часто встречается подход, в котором на бэке в отдельных процессах крутятся микросервисы, но они общаются с юзером через один API Gateway и одно клиентское приложение. Если пойти дальше, можно встретить подходы с выделением частей клиентского приложения на микросервисы (frontend microservices). Фактически, микросервис будет предоставлять клиентскую и серверную часть в пределах своих границах (поломать что-то на клиенте или API другого микросервиса становится нереально).
Назревает такая идея: положить ответственность за каждый сервис на одного человека (как минимум).
Как по мне, это имеет следующие преимущества:
- в роли фронтендера разработчик не должен заботиться о бизнес задаче, которую решают другие сервисы.
- нет частых коммуникаций между фронтендером и бэкендером (так как это один и тот же человек)
- исключено перекладывание ответственности на фронтендера/бэкендера (проще сделать минимальное API и предложить фронтендеру преобразовывать данные на клиенте так, как ему нужно, но это усложняет ему работу и ухудшает быстродействие приложения)
- можно писать код в своем стиле (особенно касается клиентской части, где можно похоливарить о kebab-case против camelCase для имен классов стилей)
Недостатки:
- необходимы навыки full track
- сложно продолжить поддержку сервиса, если с него ушел (временно или насовсем) единственный разработчик, так как кроме него мало кто имеет понятие как работает сервис внутри
Какие еще могут быть сложности с этим? Есть реальные кейсы?
Все эти пункты не основаны на практическом опыте (скорее на опыте противоположного подхода с монолитным "всем :)"), поэтому мне интересно узнать о реаьных кейсах, в которых применяется такой подход. Предполагается, что проблемы с деплоем большого количества сервисов и их связыванием уже известны и приняты как должное :)
Средний
Средний
