Для разработчиков важно адекватно оценить планы и сравнить их с продуктом, который получается в итоге. Но при этом нужно провести комплексное тестирование и обратить внимание даже на мелкие детали. Основатели компании Cruderra Алмаз и Ринат Хабибуллины рассказывают, как реализовать свою идею и не сделать так, чтобы сервис полностью отличался от оригинальной задумки.
Привычные решения и новшества
Для проектирования и мониторинга API есть много уже знакомых разработчикам API Design-инструментов: Postman, SwaggerHub, Stoplight, Readme, MuleSoft и другие, в том числе тесно привязанные к облачным провайдерам.
Сейчас разрабатываются и другие инструменты проектирования API: Redocly, Insomnia, Archbee, Cruderra и другие. В них пока нет полноценных инструментов мониторинга API, но это дело времени.
На определенном этапе перед командой разработки появляется задача сравнения проекта API с тем, что происходит в бэкенде на самом деле. И тогда инструменты тестирования и мониторинга выходят на первый план. Благодаря им можно не только отследить явные ошибочные ситуации использования API, но и выявить проблемы производительности на стыке задач APIOps, TestOps и DevOps.
Но если слишком увлечься вопросами автоматического тестирования и мониторинга, можно легко забыть про основную цель разработки. Важно наладить связь между изначальными требованиями проекта и его реальным воплощением. Архитектору проекта нужно сохранять контроль между тем, что задумано, и тем, что действительно пошло в продакшн. Это помогает актуализировать проект, отследить реальное поведение пользователей, выявить повторения, сильные и слабые стороны, чтобы предложить улучшенную версию API.
Причем контролировать API и целостность сценариев его использования нужно непрерывно, на протяжении всех витков спирали жизненного цикла разработки.
На что нужно обращать внимание при сравнении проекта и реальности
В первую очередь, проверяют работу нисходящей цепочки контроля и отвечают на пять вопросов:
- Какие есть пользовательские истории и какие из них содержат ошибки?
- Какие API Endpoints возвращают ошибочный статус? Сколько таких статусов?
- Ошибочная реакция Response Status на запрос верна? Или вызвана внутренней ошибкой обработки?
- Насколько валидны входящие и исходящие модели данных (DataModel) и заголовков (Headers)? Насколько они соответствуют изначальным требованиям?
- Верное ли значение поля (Field) передается в модели данных? Не нарушаются ли ограничения? Выставленные ограничения необходимы и достаточны?
Если ответы на эти вопросы есть, — это базовая степень контроля работы API продукта.
Но API — лишь внешний интерфейс взаимодействия с его потребителями. При реализации серверной части нужно учитывать множество входных точек, запускающих вычисления:
- API Endpoints (в том числе HTTP, gRPC, WebSockets, server-sent events, webhooks и др.);
- брокеры сообщений (Kafka, Rabbit MQ и др.);
- задачи по расписанию (jobs или workers).
Для учета этих точек недостаточно одних инструментов API Design. Обычно применяют дополнительные инструменты мониторинга — готовые или настроенные под себя (например, при помощи Grafana + Prometheus). Это помогает выявить скрытые накапливающиеся проблемы, уведомить команду разработки и принять своевременные меры.
Также нужно обращать внимание на сбор не только технических метрик, но и поведенческих. Это важно для анализа использования сценариев и входных точек API, а также поведения самих пользователей. Так продуктовая команда получает обратную связь, которая позволяет улучшить сам API. В том числе по вопросам безопасности и монетизации.
Есть уверенность, что все работает. Какие тесты необходимо провести?
ИТ-отрасли известна классическая пирамида тестирования, описывающая комплексный подход в покрытии IT-продукта тестами (по ISTQB):
- модульное;
- интеграционное;
- системное;
- приемочное.
В зависимости от продукта, его архитектуры и степени развития можно применять различные подходы и глубину тестирования.
Также для уверенности в работоспособности продукта нужно обеспечить закрытие инфраструктурных вопросов:
- включение автотестов в этапы сборки проекта в CI/CD;
- подключение рассылки оповещений (alerts) о критических состояниях системы;
- настройка мониторинга разрабатываемых сервисов, а также используемых внутренних и внешних продуктов;
- фиксация исключений и логов в отдельных системах для дальнейшего отслеживания и восстановления событий.
Выявлять проблему лучше еще до того, как пользователь сообщит о ней или уйдет. К счастью, ИТ-сообщество накопило открытую базу знаний в области тестирования. Если применять лучшие практики, то система будет работать как часы.
Над чем еще стоит поработать: будущее в этой сфере
Для разового решения задачи сравнения проекта API с его реальным воплощением вполне достаточно существующих API Design инструментов.
Однако для более глубокого контроля API требуется нечто большее. Например, Continuous API Design с инструментами мониторинга и тестирования. А если смотреть еще на один уровень глубже, то также необходимо контролировать backend, выполняющий основную работу для обслуживания внешнего интерфейса API.
С каждым годом инструменты контроля создания ИТ-продуктов совершенствуются. Появляются новые сервисы, которые делают жизнь разработчиков легче. Несмотря на внешние потрясения, ИТ-сфера сохраняет устойчивую динамику развития и потребность в удобных инструментах повышения эффективности будет только расти.
Читать далее:
«Джеймс Уэбб» прислал фото столкновения двух огромных галактик
«Бесполезная» бактерия на Земле обеспечит жизнь колонизаторам Марса
На пирамиде в Китае нашли портрет «царя предков». Он правил более 4 000 лет назад