Comments 12
:-) Главный вопрос - А что вы ожидали при начале разработки и интеграции?
В разработке и тестах интеграции (с любой внешней системы) изначально нужно опираться на принципы:
- Описание протокола обмена (не важно в каком виде) - это только основа взаимодействия
- Структуры и типы данных для обмена вероятнее всего могут не совпадать с описанием
- Все что может отличаться от идеального сценария обмена сообщениями - обязательно случится
Знакомая боль. У нас в эквайринге спасал outbox + поиск по OrderId вместо ProviderPaymentId: нотификации, пришедшие раньше коммита, не теряются, ждут в очереди и разбираются с экспоненциальным бэкoффом.
да, поиск по бизнес-ключу orderId вместо провайдерского id - к этому мы тоже пришли
провайдерский id появляется поздно и не на всех событиях, а orderId есть с момента создания намерения - outbox+бэкофф закрывают гонку "нотификация пришла раньше коммита"
про идемпотентность по намерению, а не по техническому id, у меня был отдельный разбор https://habr.com/ru/articles/1039860/
А что вы ожидали при начале разработки и интеграции?
ПМ задал четкие ожидания: фокус на запуск в краткие сроки mvp оплат по qr-коду и интеграция с 2мя шлюзами, к дедлайну все основные функции должны быть готовы к подключению первым n мерчантам. Оплаты по qr стали тогда новым направлением для компании, до этого делали только оплаты картой (2022 год).
В разработке и тестах интеграции (с любой внешней системы) изначально нужно опираться на принципы
На этом кейсе я и хочу показать на что мы опирались в начале проекта и как поэтапно трансформировалось наше мышление после столкновения с граблями в реальности. В конце статьи составил список наших инсайтов, на них мы сами опирались при интеграции следующих провайдеров в этом проекте.
return; // дубль: вторая доставка – не ошибка, а вторник
Ну вы хоть вычитывайте после генерации (:
По теме: хороший список граблей не внешнюю интеграцию. Особенно весело, весело когда сообщения приходят не в том порядке
Особенно весело, весело когда сообщения приходят не в том порядке
true story
иногда можно завязаться не таймстемпы, но их тоже можно не дождаться или получить кривыми (бывало и такое), но машина состояний работает лучше, когда разрешённые переходы зашиты в домене, и поздний промежуточный статус просто не перезатирает финальный, это то что в грабле CanTransition
Ну вы хоть вычитывайте после генерации (:
да не, это была отсылка к мему же - but for me it was tuesday
Настаивать не буду, но стиль ЛЛМ, хотя информация полезная, мысли свои.
Как говорил один мой товарищ: раньше ягоды были полезные из леса, но мало, а сейчас безвкусные, зато хватает всем. Видимо с текстами будет так же.
не скрываю - для причесывания больших текстов я юзаю ллм, чисто как инструмент
черновик, каждый кейс в нём, структура, рассуждения, выводы, грабли в которые я наступал, примеры кода, комменты под постами, и голова - мои собственные не сгенерированные )
ллм только сглаживает формулировки в длинных кусках - стиль подкручу, спасибо за честный фидбэк
если направленно искать, на хабре можно найти что угодно на любой вкус
Таймстемпы от внешних систем это абсолютное зло, у них сервера никогда нормально не синхронизированы по ntp...
Интеграция с банковскими апи это всегда игра в русскую рулетку, никогда не знаешь, какой недокументированный мусор тебе прилетит в ответе
Все тесты зелёные, платежи зависли: 5 граблей интеграции без песочницы