From 69fc906a8d24ca291a58b368ae19df4f14127d3c Mon Sep 17 00:00:00 2001 From: Sergey Konstantinov Date: Mon, 1 May 2023 18:51:33 +0300 Subject: [PATCH] minor corrections --- .../03-[В разработке] Раздел II. Паттерны дизайна API/05.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/ru/clean-copy/03-[В разработке] Раздел II. Паттерны дизайна API/05.md b/src/ru/clean-copy/03-[В разработке] Раздел II. Паттерны дизайна API/05.md index 4918553..a3da486 100644 --- a/src/ru/clean-copy/03-[В разработке] Раздел II. Паттерны дизайна API/05.md +++ b/src/ru/clean-copy/03-[В разработке] Раздел II. Паттерны дизайна API/05.md @@ -63,11 +63,11 @@ const pendingOrders = await api. **NB**: иногда можно встретить решение, при котором эндпойнт имеет двойной интерфейс и может вернуть как результат, так и ссылку на исполнение задания. Хотя для вас как разработчика API он может выглядеть логично (смогли «быстро» выполнить запрос, например, получить результат из кэша — вернули ответ; не смогли — вернули ссылку на задание), для пользователей API это решение крайне неудобно, поскольку заставляет поддерживать две ветки кода одновременно. Также встречается парадигма предоставления на выбор разработчику два набора эндпойнтов, синхронный и асинхронный, но по факту это просто перекладывание ответственности на партнёра. -Популярность данного паттерна также обусловлена тем, что многие современные микросервисные архитектуры «под капотом» также взаимодействуют асинхронно — либо через потоки событий, либо через асинхронную постановку заданий же. Имплементация аналогичной асинхронности во внешнем API является самым простым способом обойти возникающие проблемы (читай, те же непредсказуемые и возможно очень большие задержки выполнения операций). Доходит до того, что в некоторых API абсолютно все операции делаются асинхронными (включая чтение данных), даже если никакой необходимости в этом нет. +Популярность данного паттерна также обусловлена тем, что многие современные микросервисные архитектуры «под капотом» также взаимодействуют асинхронно — либо через потоки событий, либо через промежуточный pub/sub сервис, реализующий паттерн «издатель-подписчик». Имплементация аналогичной асинхронности во внешнем API является самым простым способом обойти возникающие проблемы (читай, те же непредсказуемые и возможно очень большие задержки выполнения операций). Доходит до того, что в некоторых API абсолютно все операции делаются асинхронными (включая чтение данных), даже если никакой необходимости в этом нет. Мы, однако, не можем не отметить, что, несмотря на свою привлекательность, повсеместная асинхронность влечёт за собой ряд достаточно неприятных проблем. - 1. Если используется единый сервис очередей на все эндпойнты, то она становится единой точкой отказа. Если события не успевают публиковаться и/или обрабатываться — возникает задержка исполнения во всех эндпойнтов. Если же, напротив, для каждого функционального домена организуется свой сервис очередей, то это приводит к кратному усложнению внутренней архитектуры и увеличению расходов на мониторинг и исправление проблем. + 1. Если используется единый сервис очередей на все эндпойнты, то он становится единой точкой отказа. Если события не успевают публиковаться и/или обрабатываться — возникает задержка исполнения всех эндпойнтов. Если же, напротив, для каждого функционального домена организуется свой сервис очередей, то это приводит к кратному усложнению внутренней архитектуры и увеличению расходов на мониторинг и исправление проблем. 2. Написание кода для партнёра становится гораздо сложнее. Дело даже не в физическом объёме кода (в конце концов, создание общего компонента взаимодействия с очередью заданий — не такая уж и сложная задача), а в том, что теперь в отношении каждого вызова разработчик должен поставить себе вопрос: что произойдёт, если его обработка займёт длительное время. Если в случае с синхронными эндпойнтами мы по умолчанию полагаем, что они отрабатывают за какое-то разумное время, меньшее, чем типичный таймаут запросов (например, в клиентских приложения можно просто показать пользователю спиннер), то в случае асинхронных эндпойнтов такой гарантии у нас не просто нет — она не может быть дана. 3. Использование очередей заданий может повлечь за собой свои собственные проблемы, не связанные с собственно обработкой запроса: * задание может быть «потеряно», т.е. никогда не быть обработанным;