Если говорить про асинхронные интеграции, то, конечно, без дополнительной документации не обойтись. Те же sequence диаграммы, например. Но недавно, вдохновившись успехом свагера, придумали AsyncAPI спецификацию. Несмотря на то, что спекая молодая, на нее уже делает ставку крупный энтерпрайз, например, конкуренты Альфа Банка.
SOAP API описывается в WSDL, и при наличии схемы API все преимущества использования доп. инструментария остаются прежними.
Причины, по которым важно структурированное описание API:
Поддерживать надо лишь один файл с схемой. Стоимость владения документацией ниже.
Структура описания API понятна сразу всем: клиентам, разработчикам, аналитику, который придет на замену вам.
Для клиента легко найти разницу с предыдущей версией API.
Автогенерация документации, если самой схемы недостаточно. В случае с REST просто открыть editor.swagger.io и вставить спеку.
Автогенерация клиента и сервера - стоимость внедрения и владения ниже. Это воплощенное в коде ТЗ, от которого уже никуда не деться на этапе разработки.
Не буду больше занудствовать в вашем посте, поднимающем важную тему. Если команда не готова использовать определенную спеку для описания API, то приведенного шаблона будет достаточно для документации.
В статье проповедуется contract first подход, и в тексте нет ни одного слова про OpenAPI/Swagger. Это структурированное описание API, которое могут интерпретировать программы, и, в свою очередь, генерировать серверный/клиентский код, рендерить документацию (с примерами и прочим), генерировать и исполнять интеграционные тесты и много чего еще. Совет автору и заинтересованным читателям: для проектирования API воспользуйтесь Postman или SwaggerHub или Stoplight Studio или, наконец, простым текстовым редактором с подсветкой yaml синтаксиса.
Рад увидеть вашу публикацию на хабре, получился качественный материал.
Я во многом разделяю ваши взгляды на архитектуру, выбор технологий и работу с командой.
К статье лишь хотел бы добавить пару уточнений:
У Cadence есть опенсорсная версия temporal.io.
И cadence, и temporal.io в свободном доступе под лицензией MIT.
Очередей хочется много: по одной очереди на каждого пользователя, на каждый бизнес-процесс, в том числе и на каждый платеж, который еще не завершен. В результате одновременно в системе нужны несколько миллионов очередей. Впрочем, все эти очереди довольно небольшие — каждая не более тысячи событий.
У Kafka до недавнего времени было жесткое ограничение на количество партиций (независимых очередей, для которых сохраняется требование FIFO). Сейчас его сняли, но все равно поддерживать миллион партиций в Kafka очень непросто для эксплуатации.
В Kafka партиция служит, скорее, как единица параллелизма записи/чтения сообщений, и количество партиций определяется по требованию пропускной способности для producer & consumer.
Топик, логическое представление об очереди, по-классике проектируется под один тип сообщения, а идентифицировать принадлежность события к объектам системы целесообразнее in-place из атрибутов ключа/значения сообщения - главное, правильно выбрать стратегию партиционирования для равномерного распределения сообщений и упорядоченной обработки.
А можете в двух словах раскрыть стек ABAC?
С нетерпением буду ждать отдельной публикации про имплементацию ABAC, подписался на вас.
Если говорить про асинхронные интеграции, то, конечно, без дополнительной документации не обойтись. Те же sequence диаграммы, например. Но недавно, вдохновившись успехом свагера, придумали AsyncAPI спецификацию. Несмотря на то, что спекая молодая, на нее уже делает ставку крупный энтерпрайз, например, конкуренты Альфа Банка.
SOAP API описывается в WSDL, и при наличии схемы API все преимущества использования доп. инструментария остаются прежними.
Причины, по которым важно структурированное описание API:
Поддерживать надо лишь один файл с схемой. Стоимость владения документацией ниже.
Структура описания API понятна сразу всем: клиентам, разработчикам, аналитику, который придет на замену вам.
Для клиента легко найти разницу с предыдущей версией API.
Автогенерация документации, если самой схемы недостаточно. В случае с REST просто открыть editor.swagger.io и вставить спеку.
Автогенерация клиента и сервера - стоимость внедрения и владения ниже. Это воплощенное в коде ТЗ, от которого уже никуда не деться на этапе разработки.
Не буду больше занудствовать в вашем посте, поднимающем важную тему. Если команда не готова использовать определенную спеку для описания API, то приведенного шаблона будет достаточно для документации.
Рад, что вместе раскрыли тему.
В статье проповедуется contract first подход, и в тексте нет ни одного слова про OpenAPI/Swagger. Это структурированное описание API, которое могут интерпретировать программы, и, в свою очередь, генерировать серверный/клиентский код, рендерить документацию (с примерами и прочим), генерировать и исполнять интеграционные тесты и много чего еще. Совет автору и заинтересованным читателям: для проектирования API воспользуйтесь Postman или SwaggerHub или Stoplight Studio или, наконец, простым текстовым редактором с подсветкой yaml синтаксиса.
Рад увидеть вашу публикацию на хабре, получился качественный материал.
Я во многом разделяю ваши взгляды на архитектуру, выбор технологий и работу с командой.
К статье лишь хотел бы добавить пару уточнений:
И cadence, и temporal.io в свободном доступе под лицензией MIT.
В Kafka партиция служит, скорее, как единица параллелизма записи/чтения сообщений, и количество партиций определяется по требованию пропускной способности для producer & consumer.
Топик, логическое представление об очереди, по-классике проектируется под один тип сообщения, а идентифицировать принадлежность события к объектам системы целесообразнее in-place из атрибутов ключа/значения сообщения - главное, правильно выбрать стратегию партиционирования для равномерного распределения сообщений и упорядоченной обработки.
А можете в двух словах раскрыть стек ABAC?
С нетерпением буду ждать отдельной публикации про имплементацию ABAC, подписался на вас.
Вы изобретаете каппа архитектуру. Рекомендую поликбезить сабж.