Что думаю о Swagger
Одна из самых бесполезных вещей в айти — это Swagger. Так называется система, которая отображает REST-апихи в JSON-файле. Идея хорошая, но на практике вымораживает мозг. Давно порывался написать о ее минусах, и вот на днях опять подгорело.
Если вы внедряете в проекте Swagger, то скорее всего, занимаетесь ерундой. За все годы работы мне приходилось внедрять его четыре раза, и каждый раз я не видел от него пользы. Так, болтается какая-то хрень сбоку, отнимает время и ресурсы, никто ее не смотрит. Поставьте скрипт аналитики и убедитесь, что в нем от силы одно посещение в день.
Swagger это порождение мира node.js, столь мне отвратного. Это папка node_modules с миллионом микро-файлов, хрупкие сборки и прочие фу. К счастью, появились докер-образы, но и они не без греха. Так, образ swagger-ui нельзя запустить в read-only файловой системе. Если у вас Кубернетис, придется выкручиваться.
Усилия, направленные в русло Swagger, напоминают строительство пирамид. Масштабно, неэффективно и никому не нужно. Верный признак ущербности в том, что со всех сторон плодят еще более не нужные утилиты: убогий онлайн-редактор, CLI и, конечно, ОБЛАЧНУЮ учетную запись. Для утилиты, которая по JSON рисует HTML.
Те, кто топят за Swagger, не понимают, как устроена документация в фирмах. Дело в том, что JSON не может нормально передать текст, он для этого не предназначен. Использовать для документации язык, в котором нет мульти-строк, средств акцента, ссылок и прочего — это прохладная идея.
Нормальная документация — это семейство markdown- или asciidoc-файлов, объединенных в проект. Человек садится за редактор и пишет текст ручками. Расставляет акценты, ссылки, сноски. Это трудная работа, но только так получается достойная документация.
Конечно, я за то, чтобы процесс был автоматизирован. Приложение может сбрасывать JSON-схемы в файлы, которые затем подхватит сборщик документации. Но текст должен писать человек, и обязательно упомянуть все неочевидности, которые найдутся при работе с апихой. А их, как правило, вагон: эту апишку можно вызвать только при таком условии, параметры зависят друг от друга, и так далее. Описание одного только поиска может занять два экрана с примерами. JSON-схема не передаст всех нюансов.
Верный признак того, что Swagger это ущербная технология — им не пользуются самостоятельные компании. За всю карьеру я ни разу не видел, чтобы условный Гугл, Яндекс, Амазон и прочие показывали документацию через Swagger. В фирмах разный подход, но как правило это HTML с написанным человеком текстом. Вот несколько примеров:
Кто там еще? Вконтакт, Dropbox, банки (Тинек, Сбер)… ни одна значимая фирма не пользуется Сваггером. По моим меркам это был бы позор уровня студента.
Стандартный шаблон Сваггера ужасен. Взгляните на официальное демо:
Тут красненький, тут желтенький, зеленый, выпадашечки, блин, цирк. Школьное поделие, а не документация. Этот шаблон не вписывается ни в один дизайн, каждый элемент чужероден. Нужно несколько дней на то, чтобы сверстать свой шаблон. Предлагать клиентам Сваггер — значит заведомо не уважать их.
Кроме убогого шаблона, Swagger предлагает утилиту для генерации кода приложения. Давайте честно: кто захочет строить проект на базе кодогенерации, написанной неизвестно кем? Этот код однозначно уйдет в урну. Конечно, генерация пригодится студентам для курсовой работы по предмету “введение в веб-разработку”, но и только.
В общем, прекратите страдать фигней. Хотите нормальную документацию — поднимайте проект на Asciidoc, Wiki, GitBook, что угодно. Это трудно и требует навыков выражать свои мысли понятно. Может, пока апиха в разработке и меняется каждые два дня, нет смысла писать документацию. Но не вываливайте на клиентов интерфейс Сваггера. В нем отчетливо слышна машинная природа, и по всем признакам ясно, что эта страница не для людей.
Нашли ошибку? Выделите мышкой и нажмите Ctrl/⌘+Enter
Timur Malikin, 9th Jun 2020, link
У нас бэк генерит swagger страничку с описанием api, фронтендеры рады, бэкендеры не напрягаются :)
Александр Бабин, 10th Jun 2020, link
Ну как минимум google рекомендует использовать тулы базирующиеся на OpenAPI а так же предлагает свой транслятор к swagger (так что я бы не стал говорить за все)
https://googleapis.github.i....
Не совсем понятен хейт, тк swagger дает вам бесплатную документацию API (без необходимости лезть в код, особенно если у вас к нему нет доступа) используя ваши типы и все что для этого нужно - подключить библиотеку. Понятно что написаная человеком документация гораздо лучше сгенерированной, но как мне кажется одно органично дополняет другое
Alex Mos, 11th Jun 2020, link
Мне близка ваша мысль о том, что Сваггер — признак нездорового проекта. Я обычно встречаю его в компаниях, которые занимаются постоянной гонкой, где нужно вот уже вчера зарелизить три суперсрочных фичи, бекендеры только что вывалили в сваггер кучу каких-то энпоинтов, которые никто не понимает как работают, но делай фронт, по ходу разберёшься.
А ещё любимая тема — автогенерация api-файлов на фронтенде по сваггеру. Неважно что нам нужно десяток эндпоинтов для админки, в сваггер.джейсоне их две сотни, половина из который устарели или сделаны на будущее — генерируй монструозный файл и используй только нужное.
Александр Бабин, 12th Jun 2020, link , parent
От не правильного версионирования API, а так же от глупых разработчиков (по принципу херак-херак в продакшен) вас никто не спасет. Все то же я наблюдаю и в десятках других проектов без swagger'a документации и т.д
Max Poletaev, 16th Jun 2020, link
Схема сваггера (или OpenAPI) сама по себе штука неплохая, просто не нужно воспринимать её как end-user документацию. Это именно схема — описание типов данных и эндпоинтов (как WSDL в SOAP или proto файлы в gRPC).
В отличии от маркдауна, OpenAPI схема пишется очень быстро (или вовсе генерируется автоматически), её все понимают, её проще поддерживать, а её строгость позволяет навернуть сверху некоторую интересную автоматизацию, в частности:
1. Клиенты могут автоматически сгенерировать Mock-сервер, не дожидаясь готовности сервиса;
2. В интеграционных тестах запросы и ответы к тестируемым сервисам можно сравнивать со спецификацией и, таким образом, быть уверенным, что реализация соответсвутет спеке.
Большую подробную доку никто не отменял, но она пишется именно для конечных пользователей или конечного продукта как часть проектной документации. А для внутренних интеграций, где есть прямая связь между разработчиками, OpenAPI работает нормально.
Andrey Saksonov, 19th Jun 2020, link
Сваггер штука хорошая, позволяет держать по рукой всегда рабочие примеры взаимодействия с API. Swagger-UI использовать совсем не обязательно, open-api спеку можно скармливать в постман и подобные утилиты. Если относится к Swagger-UI как к полуфабрикату и встраивать его в человеческую документацию, то получается хорошо. Вот пример https://bambora.mpymnt.com/...
Andrey Siver, 7th Jul 2020, link
Swagger возможно, что неинтересно, но в данный момент он - legacy.
Интересно OpenAPI и технологии вокруг OpenAPI:
(1) удобный визуальный редактор для спеки
(2) возможность cгенерировать худо-бедно страничку с описанием REST API, понятную для бэкендеров и фронтендеров
(3) в качестве бесплатной "плюшки", через эту страничку, как правило, можно делать живые запросы и получать живые ответы, которые фронтендеры могут использовать для заглушек
(4) возможность через спеку валидировать запросы и ответы (что для среднего проекта и выше - must have фича).
Итого, OpenAPI в данный момент решает проблемы, который есть в реальности. Можно обсуждать лишь то, насколько удачно оно их решает :).
Ну и да, OpenAPI - это не про документацию. Это про представление API.
Danil Pismenny, 2nd Nov 2020, link
Разрешите с вами не согласиться. У меня абсолютно обратный опыт. А всё потому что я чаще всего API разрабатывают на ruby через DSL на grape, который отражает всё описание в swagge автоматомr.
Например код: https://github.com/dapi/tas...
Автоматом генерирует на swagger спеку и с которой можно обращаться через web:
https://tasky.online/api
И все это работает просто подключая пару модулей типа grape-swagger.
Не представляю себе как еще можно разрабатывать и документировать API. Я так понимаю в мире clojure это делается через compojure-api
Другое дело, когда код от API лежит в одном месте, а спека к swagger лежит в другом да ещё и пишется вручную на JSON. Вот этот я не понимаю. Спекая всегда будет отставать да и трудозатраты лишние.
Егор Цукерман, 9th Dec 2020, link
согласен. мура это всё, пользоваться свагером не удобно не дружелюбно. тесты свагера как правило все кривые
Евгений Ткаченко, 25th Mar 2021, link
Хз зачем им пользоваться, если в postman можно публиковать доку, которая автоматически обновляется