[Перевод] Вы уверены, что вам нужен API?
От переводчика: При разработке бэкэнда наличие API для фронт-энда стало практически повсеместным стандартом. Однако можем ли мы называть это «настоящим» API? Предлагаем вашему вниманию интересное пятничное чтение, которое, возможно, повлияет на API, которые мы все разрабатываем.
«Слабая связанность, сильное сцепление», «сокрытие информации». Известные принципы дизайна. Тем не менее, к ним очень часто не относятся серьезно при разработке архитектуры ПО, особенно когда это касается взаимодействия между клиентской и серверной частью (фронтом и бэком на жаргоне разработчиков).
Ценность API — в сокрытии информации
Предоставляя API, системы решают, какая информация должна быть доступна из внешнего мира, а какая будет держаться в секрете («сокрытие информации»).
Почему это важно? Потому что чем объемнее API, тем дороже его поддерживать. Представьте себе крайний случай — открытие каждой детали реализации. Каждое изменение в системе может сломать код, который используют ваши клиенты. Именно по этой причине мы стремимся разрабатывать компактные API. Я писал статью (перевод на хабре) по этой теме в контексте описания шаблона «Регистрация событий».
Вне зависимости от размера, API не позволяет менять систему так, как нам хочется. Мы всегда вынуждены детально документировать API и всегда думать о том, как бы не сломать клиентский код. Изменения должны быть обратно совместимы, в противном случае придется согласовывать развертывание всех зависимых систем, что быстро превратится в ад поддержки монолитного приложения.
API как продукт
Но почему системы предоставляют так много API, если их так тяжело поддерживать? Одна из причин может быть в том, что API — та вещь, которая «продает» систему. API — это продукт, и вы зарабатываете деньги, предоставляя его. В этом случае есть смысл в подробном документировании, использовании Hypermedia и поддержке обратной совместимости. Ваши клиенты будут это ценить, и ваш продукт-API завоюет мир.
Разделение клиента и сервера
Я готов спорить, что такие API как продукт — редкость. Гораздо чаще существование развесистого API — признак плохо выбранных границ вследствие нарушения принципа «слабая связанность — сильное сцепление».
Хотя это исследование также применимо и к коммуникации «сервер — сервер», я хотел бы сфокусироваться на клиентской части. И я ставлю под вопрос утверждение о том, что нам нужен API для взаимодействия клиента с сервером.
Это естественно, что клиент и сервер имеют прочную связь, потому что каждый раз, когда нужно отобразить новые данные на клиенте, нужно переделывать сервер. Тогда почему мы пытаемся их разделить, воздвигая стену — API — между ними?
В подавляющем большинстве случаев такой дизайн обусловлен организацией или техническими обстоятельствами. Есть отдельные команды разработчиков для клиентской и серверной части, но я не уверен, что накладные расходы по поддержке API всегда принимаются во внимание при принятии решения о разделении команд.
Тяга к отрисовке на клиентской части
Ещё один двигатель — страсть к реализации клиентской части с использованием современных JS фреймворков для разработки пользовательского интерфейса, таких как Angular, React или Vue.js. В противоположность отрисовке на сервере (SSR), эти фреймворки отрисовывают интерфейс на клиентской машине (CSR) в браузере и полагаются на сервисы (REST, GraphQL,…), предоставляемые сервером для получения данных и выполнения каких-то действий.
Самодостаточность и CSR не противоречат друг другу
Хотя я думаю, что SSR сейчас сильно недооценен, я могу это понять, так как требования к клиенту гораздо лучше реализуются современными JS фреймворками.
Но… использование такого фреймворка не означает обязательное наличие API! Подумайте о поставке приложения как о самодостаточной, единой системе, которая включает в себя и клиент, и сервер! Уверен, у вас есть разделение сред выполнения, так как серверный код выполняется на сервере, а клиентский — в браузере пользователя. И это разделение требует использования REST или GraphQL, чтобы синхронизировать среды выполнения.
Я называю это мостиком, а не API, потому что изменения в серверной части идут рука об руку с изменениями в клиентской. Нет необходимости в тщательном документировании или разбираться с несовместимыми изменениями, потому что у вас есть только один клиент. И этот клиент — понятный, так как он расположен ровно в той же самой системе. Вследствие того, что клиент и сервер всегда развертываются как единое целое, исчезают проблемы документирования и совместимости.
Заключение
Технология не должна определять дизайн системы. Что касается взаимодействия между клиентом и сервером, принимайте во внимание требования к системе и решайте, хотите ли вы использовать монолитную клиентскую часть или самодостаточную, единую систему. «Слабая связанность, сильное сцепление» — мощный принцип!
Если вы решите двигаться по пути создания единой системы, то вам решать, что использовать — SSR или CSR. И, хотя зачастую понятия CSR и SPA (одностраничное приложение) часто слепливают вместе, вы можете использовать CSR и разрабатывать модульную клиентскую часть.
Ссылки
У меня появилась идея написания этой статьи, когда я слушал подкаст SoftwareArchitekTOUR — Episode 82 (German) с Stefan Tilkov и Eberhard Wolff. Спасибо за вдохновение!
Хорошие источники для более глубокого погружения в самодостаточным системам и микро-фронтам:
Self-Contained Systems
Micro Frontend
