У меня ощущение, что обсуждения — делать контракты в начале или генерировать их из кода — так же бесконечны, как и спор о том, что было первым — курица или яйцо.

При этом обсуждения, как правило, касаются техники, а не подхода, что приводит к большой ошибке. Вообще не обсуждается глобальная проблема которая решается.

Кто знаком с уровнями требований, понимает, что обсуждение идет как правило на архитектурном уровне, а не на пользовательском или технологическом уровне.

Решение этой задачи должно быть на уровне подхода, потому что, выбирая подход, мы глобально решаем ту или иную проблему.

- Разработка с контрактов позволяет участникам работать параллельно.
- Генерация документации из кода - последовательно.

Если второй вариант подходит для проекта, тогда его и используйте. Если сроки важны, команда большая, то эффективнее будет использовать первый вариант.

Все гибридные решения, например, в простой форме описывать API в wiki, а потом делать генерацию, — это monkey job. Нужно поддерживать документацию в двух местах, непонятно зачем.

Делитесь своим мнением в комментариях! 👇

#контракты #документация #разработка #API #архитектура #требования #команда #эффективность

Последние две недели ходил с классной идеей, которую хотел реализовать и выложить на GitHub — резюме как код.

Суть простая: описываем по определенному шаблону в yml файле свое резюме, далее в рамках CI/CD процесса происходит генерация персонального сайта с резюме и блогом, создание резюме в виде PDF файла и публикация/обновление резюме на hh.ru, Habr.Карьера и LinkedIn.

Но когда сел делать исследование перед разработкой, суровая реальность заставила похоронить идею. Habr.Карьера не поддерживает API для кандидатов, только для рекрутеров. В LinkedIn также не нашел метода для работы со своим резюме, кроме его получения. Только hh.ru молодцы — позволяют работать с резюме с помощью API, но делать приложение только для них явно нецелесообразно.

Вот так суровые реалии ограничивают наши возможности. Но ничего, будем искать другие пути и идеи!

#IT #DevOps #резюме #карьера #API #GitHub #CICD #автоматизация

Уже во второй раз буду участвовать в конференции Analyst Days! На этот раз расскажу о том, как работать с AsyncAPI — от проектирования до поддержки.

В своем докладе я разберу все аспекты разработки и документирования асинхронных API с использованием спецификации AsyncAPI. Особое внимание уделю ролям системных и бизнес-аналитиков, методам создания и управления спецификациями, а также инструментам, которые помогут вам работать с AsyncAPI.

Мои подписчики получат инсайты раньше всех, так что следите за обновлениями! 😉

Если хотите узнать больше — вот ссылка на доклад в расписании: Доклад на Analyst Days

#AnalystDays #AsyncAPI #API #системныйанализ #бизнесанализ #разработка #документация #автоматизация #IT #контракты #тестирование

Готовлю доклад по AsyncAPI, обещал рассказать.

AsyncAPI — это спецификация для документирования и проектирования асинхронных API. В отличие от привычного REST, здесь речь идет о взаимодействии между сервисами через события, сообщения и очереди. Это особенно актуально для EDA, микросервисов, IoT-устройств и любых систем, где важен асинхронный обмен данными.

AsyncAPI помогает упорядочить и стандартизировать процессы работы с асинхронными коммуникациями. Это упрощает как разработку, так и поддержку проектов, где задействованы сложные архитектуры. По сути, это своего рода OpenAPI, но для асинхронных систем. Если с ним знакомы - удивитесь как похож синтаксис.

Основное преимущество — улучшение командной работы. AsyncAPI делает взаимодействие между разработчиками, тестировщиками и аналитиками более прозрачным. Все понимают, как работают события, и какие данные передаются. Это снижает ошибки и упрощает тестирование.

Кодогенерация и автоматизация — вот что мне больше всего зашло. Вы буквально можете сгенерировать код клиента или сервера на основе спецификации, а это экономит кучу времени. AsyncAPI отлично работает с современными DevOps процессами, что делает релизы более быстрыми и стабильными.

Если вы работаете с событиями, настоятельно рекомендую попробовать AsyncAPI в вашем следующем проекте.

Интересно, кто уже внедрил у себя? Пишите в комментариях! 👇

#AsyncAPI #API #микросервисы #IoT #документация #кодогенерация #DevOps #технологии #IT

Открыл для себя HTTPie - это как curl, только для людей:

# Устанавливаем на мак
brew install HTTPie

# Выполняем запрос
http GET https://namaztimes.kz/ru/api/cities\?id\=almaty\&type\=json

Удобный синтаксис, красивый вывод, поддержка JSON из коробки. После него к curl возвращаться не хочется!

#API #CLI #DevTools

Bruno (документация) - отличная альтернатива Postman и Insomnia для тестирования API. Главная фишка - коллекции хранятся в git как обычные файлы. Можно версионировать, ревьювить и хранить рядом с кодом.

Поддерживает переменные окружения, пре/пост процессинг и даже запуск тестов в CI. А еще есть CLI для автоматизации.
В отличие от Postman - полностью опенсорс и бесплатный (платные тарифы тоже есть, но бесплатного варианта за глаза). Из плюсов - нет облачной синхронизации, все через git и полностью офлайн, что редкость для со временного ПО.

#API #testing #DevTools

Знаете, сколько раз я пытался начать вести бюджет? Даже считать не хочу 😅 Всё упиралось в одно и то же – необходимость каждый день, как прилежный бухгалтер, записывать все траты. В эпоху наличных это было вообще что-то из разряда фантастики – вечером сидишь, пытаешься вспомнить, куда же ушли эти 500 рублей 🤔
С картами стало немного легче, но всё равно приходилось каждый вечер, как на второй работе, заполнять таблицы или приложения. И знаете что? Хватало меня обычно на пару недель, максимум на месяц.

Но всё изменилось, когда я наткнулся на Дзен Мани ✨ Главная магия в том, что он сам парсит все операции (да-да, можно наконец-то забыть про ручное внесение!). А самое крутое – он правильно обрабатывает переводы между своими счетами и даже между моими счетами и счетами жены.

Для семейного бюджета это просто космос! 🚀 Представляете, теперь мы видим все операции со всех наших счетов, и не нужно высчитывать, кто кому сколько перевёл. Раньше приходилось записывать переводы друг другу как "затраты", что полностью убивало статистику. А если кто-то хочет держать часть счетов в тайне от второй половинки – такая опция тоже есть 🔒

Ну и как программиста меня особенно порадовало наличие API! Уже успел собрать три небольших проекта на его основе, и в голове крутится еще парочка идей 🛠️

А как у вас обстоят дела с ведением бюджета? Какие приложения или сервисы используете? Что в них нравится, а что бесит? Делитесь опытом!

#финансы #бюджет #дзенмани #программирование #api #семейныйбюджет #автоматизация

Устал от холиваров 'gRPC быстрее' против 'REST привычнее'? Давайте о главном - КОНТЕКСТЕ использования.

Микросервисы внутри периметра? gRPC однозначно: контракты, производительность, удобство поддержки. Но стоит выйти за периметр...
Делаем API для React-фронта? REST + OpenAPI. Иначе намучаетесь с grpc-web, прокси и тонной лишнего кода на клиенте. Enterprise интеграции? REST снова выигрывает: у условного банка-партнера серверы еще на SOAP могут работать, не то что gRPC.

Мой опыт: используем gRPC между своими бекенд сервисами, REST для внешних API.

#architecture #api #microservices"

Одного PKCE для SPA уже мало. Почему? Участились случаи token theft даже с правильно настроенным OAuth 2.0.

Варианты улучшений:

Browser fingerprinting (защита от token replay)
Rate limiting по комбинации IP + fingerprint
Anomaly detection по паттернам запросов

Важно: это не серебряная пуля, а набор инструментов. Выбирайте исходя из модели угроз. Не сложно реализовать - browser fingerprinting и rate limiting по device ID, но даст достаточный уровень безопасности.

#security #oauth #api"