Я обмениваюсь электронными письмами и мнениями с коллегой, находящимся буквально на другом конце планеты (я в Испании, он в Сиднее) по проблемам современных SPA и RESTful API. Вот в чем дело, постараюсь быть краток.

Проблемное пространство

С распространением архитектурного подхода Микросервисы мы наблюдаем тенденцию к проектированию наших систем на основе детализированных диалоговых API-интерфейсов RESTful. Это создание SPA на основе API.

  • Эти API не соответствуют потребностям пользовательского интерфейса. Полная остановка. Они предназначены для раскрытия бизнес-процессов и данных. Это все, что волнует разработчиков API, и, поверьте мне, UX не является частью процесса проектирования RESTful API.
  • Это означает, что у нас может оказаться множество API для одной функции пользовательского интерфейса и, что еще хуже, отсутствие API или представления ресурсов для многих функций пользовательского интерфейса.
  • Мы не можем создать новый API или спроектировать новое представление ресурсов, потому что это занимает слишком много времени. Таким образом, разработчики внешнего интерфейса в конечном итоге создают сверхиндивидуальное решение, организуя слишком много вызовов API для имитации необходимого им представления ресурсов. Это приводит к неэффективному или небезопасному коду.

Как следствие, разработчикам пользовательского интерфейса приходится много манипулировать, чтобы учитывать пользовательские требования и функциональные требования в создаваемом ими приложении на основе API. И, конечно же, это должны быть они, потому что они понимают оба мира: пользовательский интерфейс и API. Не беспокойтесь, в этих командах всегда должна быть дополнительная ловкость.

Что мы можем сделать?

Таким образом, если мы все понимаем формулировку проблемы, мы можем не согласиться с ее решением. Кто-то может подумать: «Эй, не пытайтесь вскипятить океан, есть проблемы, которые вы не можете решить во внешнем интерфейсе» или «это организационная проблема». И я склонен согласиться. При создании цифровой платформы это означает много вещей, и одна из них заключается в том, что всем необходимо изменить мышление в сторону цифровых технологий: маркетинг должен обеспечить цифровой продукт, требующий минимального взаимодействия с конечным пользователем; Архитектура должна предоставлять цифровые микросервисы; Бизнес-аналитики должны перейти к цифровому мышлению; а дизайнеры должны понимать, что мы больше не в 2002 году, и наличие внешнего интерфейса с 50 полями может не соответствовать цифровому продукту и архитектуре.

Поэтому, взяв на себя решение с организационной точки зрения, некоторые компании придумали новую роль: Digital Engineer. Это роль, которая действует как связующее звено между всеми заинтересованными сторонами, описанными ранее. В этом конкретном случае использования это будет человек, который сообщает дизайнерам и бизнес-аналитикам, что в их работе есть некоторые ограничения, заданные палитрой микросервисов и представлений ресурсов, доступных в архитектуре. Таким образом, мы гарантируем, что UX соответствует спецификациям API, но я не уверен, что подобное ограждение креативности является хорошим подходом. Особенно путем продвижения ограничений, которые исходят из очень ориентированного на процессы, даже бюрократического мира (т. е. способа представления и последующего раскрытия данных).

О, это лучше, мой друг

С другой стороны, мой коллега в Сиднее требовал чего-то более прагматичного. Он сказал: «Эй, я знаю, мы не можем исправить мир, но мы можем сделать что-то во внешнем интерфейсе, что, по крайней мере, сделает нашу жизнь проще». Я боялся, что мы переусердствуем с дизайном внешнего интерфейса, создавая универсальное суперрешение. Но его доводы начали обретать смысл:

  • Доступность. В 80% случаев, когда мы начинаем создавать интерфейс, API еще не готовы. Нам нужно найти механизм, который поможет нам начать без ожидания.
  • Стабильность. Мы не можем сказать бизнесу, что пользовательский интерфейс и UX, которые они ожидают, невозможны, потому что существуют ограничения в способе представления и раскрытия данных.

Затем он предложил то, что, как я обнаружил через некоторое время, помечено как паттерн Backend for Frontend. По сути, это означает, что мы можем создать фасад API RESTful в пользовательском интерфейсе, который будет использоваться пользовательским интерфейсом, который имитирует специальный бэкэнд для этого конкретного пользовательского интерфейса.

  • Доступность. Интерфейс данных доступен, пока мы строим фронтенд, потому что этот компонент реализован во фронтенде разработчиками пользовательского интерфейса. Этот посредник предложит новое представление данных и ресурсов пользовательскому интерфейсу. Данные также будут доступны через новый интерфейс GraphQL. Таким образом, нам не нужно обращаться к нескольким конечным точкам, чтобы получить нужные нам данные, поскольку разработчики пользовательского интерфейса теперь будут выбирать только те поля, которые необходимы из новой схемы.
  • Стабильность. BFF предоставляет модель ресурсов и данные, необходимые для пользовательского интерфейса. Этот фасадный компонент будет извлекать ресурсы REST из API (данные SoR), адаптировать их к промежуточному представлению, более соответствующему потребностям пользовательского интерфейса, и открывать их через новый интерфейс GraphQL для окончательного сопоставления с моделью представления (компоненты пользовательского интерфейса). И все это происходит во внешнем интерфейсе, так что в некотором смысле это похоже на UX API. Да, здесь мы говорим о интерфейсных API. Это также означает, что нет необходимости реализовывать сложную и неэффективную логику в пользовательском интерфейсе для сбора данных, необходимых для отображения, из несовместимых API-интерфейсов RESTful.

Конечно, это наша интерпретация паттерна. Кто-то может подумать, что BFF — это еще один серверный компонент или промежуточное ПО, но в этом и заключается магия паттернов: мы даем ему ту реализацию, которую хотим.

Мы, наверное, попробуем эту модель. Хотя бы потому, что, как упоминает Ян Робинсон в этом посте от 2006 года (черт возьми, эти вещи всегда стареют), успех API зависит от его потребителей:

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

Это было хорошо сказано, Ян, спасибо.

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