Comments 13
В последней API SuperJob используется декларативный и строго специфицированный стандарт JSON:API
Приятно видеть еще одну компанию, использующую JSON:API.
Для интересующихся, по ссылке можно прочитать сравнение с GraphQL и REST.
https://dri.es/headless-cms-rest-vs-jsonapi-vs-graphql
Конечно, можно пометить устаревшими старые поля, эндпоинты, атрибуты и связи, и со временем от них избавиться. Но при активном развитии API в документации все равно накопится чересчур много устаревшей информации.
Т.е. у команды нет времени заниматься техническим долгом. Тогда о чем собственно речь? Если у команды нет времени заниматься нормальной разработкой - ей никакие подходы не позволят сделать хорошо. Потому что «хорошо» требует времени.
Ну и о самом варианте:
После того как вы вынесли API за пределы бэкенда
т.е. потратится n-количество времени
и изолировали код
аналогично
можно пилить сервисы
аналогично
модифицировать монолит
аналогично
и не бояться сломать API.
Боятся сломать что-то тогда, когда это «что-то» не покрыто полноценными тестами. А если команда не пишет тесты, или пишет их для галочки на 10% функционала - то такой команде ничего не поможет.
Потому что сам движок API теперь лежит отдельно и на лету собирается из версионированных конфигов.
Я честно говоря так и не понял, чем предложенный вариант лучше. Бардак в API появляется тогда, когда 1) у команды нет времени заниматься техдолгом 2) у команды нет времени рефакторить старый код, когда он не соответствует новым требованиям бизнеса 3) когда у команды нет времени собраться, и продумать архитектуру усложнившейся бизнес-логики
И как описанный способ, внедрение которого также потребует кучу времени, решит проблемы команды, у которой этого времени нет - непонятно. В статье описан классический подход, когда делали-делали как получится, потом осознали проблему, подумали над ней, выработали и реализовали системное решение, и стало лучше. Ну как бы логично. Конкретное системное решение - уже дело десятое, и для каждого проекта, со своими особенностями, это решение может быть разным.
Разработчики SuperJob нашли собственную реализацию решения проблемы, которая при вынесении спецификации API в конфигурационные файлы, показала отличные результаты
Подозреваю, что решение временное, лет на 5-10. Потому что необходимость поддержки десятков разных API - это уже фактор «что-то не то» на уровне компании.
Доводилось работать с API райффайзенбанка, там нам как-то пришло сообщение «такой-то формат данных будет поддерживаться еще месяц, нужно переписать на такой формат». Т.е. просто ультимативным способом внешним клиентам говорится, чтобы они перестали пользоваться старым API и переходили на новое.
P.S.
Против самой статьи, если она подается как «у нас была проблема, и мы решили её таким способом» ничего против не имею, но часто, такое подается как универсальная волшебная палочка, которая «вжух» и исправит все проблемы в компании. Если нет времени на нормальную разработку - никакая волшебная палочка не поможет.
Не согласен с автором по многим пунктам. Хотел написать длинный комментарий, но комментатор выше уже все разложил по полочкам.
Могу только добавить советы:
прокачать скилл гуглинга: любая проблема почти наверняка у кого-то уже была, и возможно уже исследована вдоль и поперек с пометками где лежат грабли
почитать умных людей, например этих https://habr.com/ru/company/piter/blog/472522/
Где-то на середине статьи сложилось мнение, что авторы "забыли", что есть замечательный паттерн "команда" Пришла в голову мысль, что версионирование вполне можно организовать на его основе. При этом не надо будет делать своих параметров конфигураций и прочих причудливых вещей. Вся конфигурация может быть выполнена кодом (например, с помощью аннотаций как сейчас можно) На мой взгляд трудозатрат будет меньше и вход "плавнее".
Имхо, лучше посмотреть запись доклада, там и ссылки на инструменты есть, и интересные вопросы задают в конце, после которых суть, что именно было сделано, становится понятнее.
Но всё равно спасибо за конспект!
Коллеги, спасибо за вопросы, и за критику тоже. Я обязательно отвечу и/или разъясню... в ближайшем будущем ;) Сейчас некоторый цейтнот наблюдается, как только разберусь - сразу сюда приду, комментировать, отвечать, объяснять ;)
Статья + комменты к ней на уровне, было полезно
Довольно интересная статья, но упоминаемые через слово "Команда SuperJob / Разработчики SuperJob" очень достали. Моргните два раза, если на этом настоял отдел маркетинга.
Версионирование API или единая кодовая база для всех версий