🔐 Что же такое JWT, access token и refresh token
и почему это тебя постоянно разлогинивает ☹️

⤵️ Наверняка у тебя бывало такое:
сидишь себе спокойно на сайте, занимаешься своими делами…
и вдруг раз:
👉 сессия истекла
👉 нужно войти снова
👉 авторизуйтесь повторно
А ты такой:
😐 да я буквально десять минут назад заходил...

🟠🟠🟠🟠🟠
⤵️ На самом деле за этим стоит довольно важная техническая штука,
с которой аналитики сталкиваются буквально на каждом шагу.
⤵️ Речь идёт о🤩токенах авторизации🤩
и чаще всего в их устройстве встречаются:
🪵 JWT-токен
🪵 access token
🪵 refresh token
Звучит это куда страшнее, чем работает на самом деле))

🟠🟠🟠🟠🟠
🤔 Если попробовать объяснить совсем просто:
😔Когда ты вводишь свой логин и пароль,
то сервер их проверяет и как бы говорит:

👍 "Хорошо, этому пользователю можно доверять"

😔После такой проверки сервер выдаёт тебе access token,
это такой специальный временный ключ доступа.
😔Теперь каждый раз, когда ты обращаешься к сайту,
клиент (фронт) отправляет этот токен вместе с запросом, словно говоря:

🫶 Привет, это снова я, пропустите плиз

🟠🟠🟠🟠🟠
⤵️ И вот тут мы подходим к JWT (или JSON Web Token)
Это просто один из популярных форматов, в котором такой токен может быть сделан.
Внутри него обычно содержится вся нужная информация:
👉 кто ты как пользователь
👉 до какого момента этот токен вообще действителен
👉 какие у тебя есть права или роли в системе
и, конечно, специальная подпись, чтобы никто не смог подделать этот токен.
😔 Так что это вовсе не какая-то "магическая строка", а вполне чётко организованные данные.

🟠🟠🟠🟠🟠
💙Но есть одна загвоздка.
❌Если access token будет действовать вечно, это становится небезопасно.

Представь, если его кто-то украдёт, то получит доступ навсегда 😬
Поэтому access token обычно не живёт долго:
👉 всего пять минут, или полчаса, но максимум час

🟠🟠🟠🟠🟠
⤵️ И чтобы пользователю не приходилось постоянно заново вводить пароль,
когда access token истечёт, придумали 🤩refresh token🤩
💙Access token можно представить как одноразовый пропуск, чтобы пройти в офис.
💙А refresh token это как твой постоянный документ,
по которому можно прийти и получить новый временный пропуск 🤭

😔 Когда срок действия access token заканчивается:
👉 фронт направляет серверу refresh token
👉 сервер внимательно его проверяет
👉 и, если всё в порядке, выдаёт новый access token.

При этом обычный пользователь чаще всего вообще ничего такого не замечает)

🟠🟠🟠🟠🟠
⤵️ А вот если и refresh token уже просрочен или по каким-то причинам стал недействительным,
тогда тебя и выкидывает на страницу входа.
😔 Вот почему иногда сайт:
👉 просто спокойно обновляет твою сессию, и ты продолжаешь работать
а иногда:
👉 требует войти заново

🟠🟠🟠🟠🟠
🤩 И зачем, спрашивается, всё это полезно понимать аналитику?

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

⤵️ И в задачах то и дело всплывают вопросы, например:

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

🟠🟠🟠🟠🟠
🚩И вот в такие моменты очень здорово помогает
не просто знать, "что нажать в интерфейсе",
а понимать, что на самом деле происходит внутри под капотом.

🚩 Ведь чем дальше ты растёшь в аналитике,
тем чаще начинаешь видеть систему как единое целое,
а не просто набор отдельных экранов 😊

📈 Есть ощущение, которое рано или поздно накрывает многих аналитиков.

👉Вроде бы внешне ничего особо не изменилось:
ты всё так же ходишь на созвоны, пишешь требования, обсуждаешь задачи.
👉Но внутри уже начинаешь замечать:
💙задачи стали даваться легче
💙в новых системах разбираешься быстрее
💙к тебе всё чаще приходят что-то уточнить или посоветоваться
👉Ну и мысль наклёвывается:
😐 а я вообще всё ещё на том же уровне?
🟠🟠🟠🟠🟠
Самое интересное, что рост в аналитике редко ощущается резко...
👉 нет такого, вчера был джуном, а сегодня проснулся сеньором)

👉Обычно это очень такой..незаметгный процесс:
➖ тебе начинают давать более сложные задачи,
➖ потом подключают к важным обсуждениям,
➖ потом ты внезапно становишься человеком, который:
может разобраться/сходит уточнит/дожмёт задачу/поймёт, отчего вдруг всё рухнуло
👉И только спустя время доходит:
🫠 ответственности, знаний и нагрузки уже сильно больше, чем раньше.
🟠🟠🟠🟠🟠
При этом зарплата иногда будто вообще не замечает
твоего внутреннего апгрейда))
и вот это уже довольно обидно..
👉 потому что ты уже работаешь сильно иначе, мыслишь иначе, берёшь на себя больше,
а по бумагам можешь всё ещё оставаться на прежней позиции, вроде бы...
🟠🟠🟠🟠🟠
💙 Причём многие очень долго обесценивают свой рост.
Кажется, что "ну это все умеют", "я просто привык", "да я ещё не настолько сильный"
👉 Хотя если посмотреть на себя год назад - разница уже огромная.
Ты быстрее понимаешь задачи, лучше чувствуешь систему, меньше тонешь в информации
и уже совсем по-другому разговариваешь с командой.
❗️И это как раз тот рост, который не всегда видно сразу, но который очень хорошо ощущается в работе.
🟠🟠🟠🟠🟠
👉Проблема только в том, что компании редко сами приходят со словами:
"мы заметили, как ты вырос,
вот тебе новая зарплата 👍"
👉Так что приходится учиться:
💙 замечать свой уровень
💙 нормально рассказывать о своём опыте
💙 собирать достижения
💙 смотреть рынок
💙 и не бояться ходить по собеседованиям

📌 Потому что быть сильным специалистом и уметь себя продать - это, к сожалению, не одно и то же

💭 Почему Scrum поначалу кажется какой-то непонятной историей
(и что тогда делать аналитику, когда он в это попадает)

✳️ Когда приходишь в айтишку, иногда такое чувство,
что все вокруг говорят на каком-то своём языке 😶
😔 Вот, например, слышишь:
- "Возьмём это в следующий спринт"
- "Нужно оценить задачу"
- "Закинем на груминг"
- "Обсудим на ретро"
Поначалу же вообще ничего не ясно, что происходит.
Все только и делают, что совещаются, двигают эти карточки в Jira,
что-то там горячо обсуждают, а ты вообще не шаришь...😕

💡 Но Scrum гораздо понятнее, чем кажется на первый взгляд.
Если уж совсем просто объяснить, то
Scrum - это просто-напросто метод, как команде выстроить работу, чтобы не браться за всё подряд разом и при этом не захлебнуться в задачах.
➖➖➖➖➖
➡️ Вот приходит, например, бизнес и озвучивает:
"Нужно переделать личный кабинет"

😔На первый взгляд ничего страшного, пока не углубишься, ведь внутри кроется:
новый дизайн, изменения API, новые роли пользователей, уведомления, новые поля, изменения логики
😔И если просто так взять и броситься делать всё сразу, то уже через пару недель можно обнаружить,
что про половину всего благополучно забыли, а вторую половину каждый понял по-своему 😶

✅ Вот поэтому и начинают всю работу делить на кусочки поменьше.

И вот тогда-то и всплывают все эти словечки:

✳️Бэклог - это, по сути, такой большой список всего, что нужно сделать, а также разных идей и просто наших "хотелок".
✳️Спринт - это такой небольшой, но чётко ограниченный отрезок времени для работы (скажем, пара недель), за который команда успевает взять и выполнить лишь определённую часть из этого бэклога.
✳️Дейлик - это коротенькая ежедневная встреча, чтобы быстро свериться: все ли идут по плану, или кто-то вдруг застрял и ему нужна помощь.
✳️Ретро - это собрание, где мы вместе думаем, что же у нас пошло хорошо, а что бы хотелось доработать и улучшить.
✳️Груминг - это такая встреча, где команда прямо-таки препарирует задачи, вычищая из них все непонятки и загадки вроде:
"нужно доработать интеграцию"

И вот тут-то на сцену выходит аналитик.
Думаем, многие поначалу видят это примерно так:
аналитик написал все требования ➡️ передал их кому надо ➡️ и пошёл себе дальше по своим делам.

💡 Но в Скраме всё устроено по-другому.
Аналитик же постоянно находится в самой гуще событий, внутри всего процесса:
➡️ активно помогает разбираться в задачах
➡️ отвечает на все возникающие у команды вопросы
➡️ уточняет требования до мелочей
➡️ постоянно взаимодействует с бизнесом
➡️ выискивает те сценарии, которые кто-то мог не учесть
➡️ и вообще помогает не растерять нить логики по ходу дела

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

‼️ И если свести всё к одной главной мысли, то вот что получится:
Скрам придумали вовсе не потому, что люди без ума от бесконечных встреч 😶
Он просто необходим, чтобы вся команда двигалась в одном, чётко заданном направлении и не выяснила спустя месяц,
что каждый из нас на самом деле строил что-то совершенно своё.

⚙️ Аналитик, проектировщик, архитектор - в чём разница?

💙Когда кто-то говорит: "я аналитик", сразу думаешь
"ну что ж, начинается игра в угадайку" 😑
Ведь где-то он занимается сбором требований,
в другом месте проектирует API,
а то и вовсе погружается в архитектуру, подбирает методы интеграции.

💙Отсюда, собственно, и появляется ощущение,
что аналитик, проектировщик, да и архитектор ➡️ это, по сути, лишь разные слова для одной и той же деятельности.

🤩Однако, если попробовать всё это упростить,
картинка вырисовывается примерно такая:
😔Представим задачу
нам надо организовать вход на платформу через Госуслуги.
Пользователь нажимает кнопку ➡ проходит авторизацию ➡ и, вуаля, оказывается в своём личном кабинете.

😔Вот так, в одном предложении, вся задача и описана)
А вот дальше уже начинается движ

🤩 Итак, аналитик:

🔴сперва разбирается, кто вообще может пользоваться входом через Госуслуги
🔴 потом выясняет, что же делать, если у пользователя уже есть аккаунт
🔴 думает, как правильно связать профили
🔴 выявляет, какие ошибки могут возникнуть
🔴 решает, что конкретно показывать человеку
🔴 и, конечно, учитывает все ограничения, которые есть со стороны бизнеса.

То есть аналитик отвечает на вопрос:
что именно у нас тут должно функционировать?

🤩 Потом приходит проектировщик:

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

То есть:
как это будет устроено?

🤩 А потом архитектор смотрит на всё это
и начинает задавать уже другие вопросы:

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

То есть:
а всё ли мы делаем правильно, строя это?

😔Потому что на реальных проектах роли часто смешиваются,
ведь на настоящих проектах все эти роли нередко переплетаются:

👌Системный аналитик вполне может сидеть и проектировать API.
👌Проектировщик запросто способен углубиться в обсуждение архитектуры.
👌Архитектор же иногда и сам погружается в бизнес-логику.

😔Поэтому если кто-то говорит:
"У нас аналитики этим не занимаются"
или
"Это работа архитектора"

то сразу хочется уточнить:
а кто у вас, собственно, скрывается под этим словом? 🤨

🖌 Грамотная постановка задачи UX-дизайнеру

©️Если ты только недавно начал взаимодействие с дизайнерами,
то нужно запомнить истину:

Если ТЗ для дизайнера изначально было не очень,
то даже самый красивый макет вряд ли вытянет ситуацию.

©️Потому что иногда задача прилетает примерно такая:
"Нужно сделать страницу регистрации. Чтобы было современно, удобно и красиво".
⏩А дальше дизайнер сидит и начинает гадать:

🔵Красиво это как? Современно это как?
🔵Кто вообще пользователь? Что он делает?
🔵Какие ограничения есть?
🔵Это новая страница или переделка существующей?
🔵Что обязательно должно остаться?
🔵Есть ли ошибки? Есть ли роли? Есть ли состояния?

И проходит пара-тройка дней, а результат....ну, вы знаете этот сценарий ⤵️
🟣 дизайнер нарисовал
🟡 аналитик посмотрел
🔵 продукт посмотрел
🟢 разработчик посмотрел
➡️ все сказали: "ну не совсем то" 🙈

✳️ И запускается карусель бесконечных уточнений:
💭 а давайте ещё вот это добавим
💭 а здесь перенесём
💭 а мы забыли важный кейс

Хотя на самом деле корень всех бед лежит куда глубже,
и проявился он намного раньше.
Когда мы даём задание дизайнеру, ему ведь не просто красивые пиксели нужны
и не пожелания в стиле "хочу как у Тинькофф", ему нужен контекст.
➡️ Со временем собирается минимальный набор примерно такой:

📌Что делаем:
Не "новый экран".
А: страница регистрации для новых поставщиков

📌Зачем делаем
Не "так захотел бизнес".
А: "сейчас пользователи не понимают, какой вариант регистрации выбирать, из-за чего растёт количество ошибок".

📌Кто пользователь
Новичок? Опытный пользователь?

📌Какой сценарий проходит человек
Нажал кнопку → открыл страницу → ввёл данные → получил результат

📌Все состояния
Загрузка, Ошибки, Пустые данные, Успех, Ограничения

📌Что нельзя менять
Вот этот пункт почему-то регулярно забывают 🙂
А потом оказывается:
"Ой, этот блок нельзя трогать, он приходит из другого сервиса"
или
"Ой, здесь юридический текст обязателен"
или
"Ой, эта кнопка завязана на старую логику"

💡И вообще,
если правильно поставить задачу дизайнеру, это сэкономит время не только ему,
выигрывают от этого абсолютно все)
‼️ Ведь тогда аналитику не придётся сто раз переделывать требования,
разработчик не будет забрасывать уточняющими вопросами,
а тестировщик точно поймёт, что же мы имели в виду под загадочным "удобно".

👨‍🎨 Фреймворки для аналитика: какие бывают и зачем нужны

Если собрать в одной комнате десять аналитиков и спросить
какой фреймворк самый важный, через пять минут начнётся драка.😱

💥 Потому что кто-то скажет BPMN, кто-то начнёт защищать UML, кто-то вспомнит про C4,
а кто-то вообще заявит, что главное это SQL и больше ничего в жизни не нужно.
💥 Новичков это часто пугает.
Складывается впечатление, что нужно срочно выучить все существующие схемы и нотации.

💥 А потом открываешь BPMN, видишь полсотни значков, ромбиков и стрелочек,
и начинаешь подозревать, что идти в аналитику было ошибкой...🤦‍♂️
💥 Хотя большинство фреймворков нужны для довольно простой вещи:
они помогают ответить на конкретный вопрос, разберём:

📌 BPMN

💭 Он нужен, когда предстоит разобраться в запутанном процессе:
Кто и что делает, в какой момент времени, какое действие запускает следующий шаг.
✅ Если вы работаете с согласованиями, сложными закупками или документооборотом,
то этот инструмент здорово упростит вам жизнь.

📌 UML Sequence Diagram

💭 Диаграмма последовательности UML работает иначе.
Она нужна для понимания того, как системы общаются между собой:
кто кого вызывает, какие методы при этом дергаются и что возвращается в ответ.
✅ Это спасает при интеграциях, когда в цепочке участвуют хотя бы пять сервисов,
обсуждать их на словах трудно, люди просто не могут удержать всю эту архитектуру в голове.

📌 ER-диаграмма

💭 ER диаграмма помогает разобраться с данными.
Вы смотрите на нее и понимаете, какие сущности есть в системе, как они связаны и где лежат.
✅ Это очень выручает, когда вы раскапываете новую для себя систему или проектируете изменения в базе данных.

📌 User Story Map

💭 USM позволяет разложить крупную задачу на понятные пользовательские сценарии.
✅ С ней гораздо проще договориться, что реально нужно для первой версии продукта,
а что можно спокойно отложить на потом.

📌 CJM (Customer Journey Map)

💭 А вот CJM смещает фокус на самого человека.
Эта карта показывает систему глазами пользователя:
где он путается, на каком шаге начинает злиться и где вообще бросает процесс на середине.
✅ Это нужно, чтобы понять поведение людей, а не техническую сторону проекта.

‼️ Но сами по себе эти фреймворки не имеют никакой ценности.
Компании не нанимают аналитика только за умение красиво рисовать схемы,
а нанимают за способность разобраться в процессе и найти решение.

Просто иногда нарисовать BPMN оказывается самым быстрым способом объяснить этот процесс команде,
то же самое касается UML, ER и любых других инструментов.

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

☹️ Типовые факапы в интеграциях и как их избегать

🔴Интеграции штука вроде бы простая, но на деле часто подкидывает сюрпризы.🙏
Вот сидишь на груминге, всё выглядит максимально безобидно:

👉 взять данные из соседней системы
👉 другая команда даст апишку
👉 мы вызовем метод
👉 и нужные данные отобразятся

Звучит как задача на пару дней)
⚪️А потом (как обычно) оказывается, что у интеграции свои законы.

За несколько лет работы мы заметили, что большинство проблем возникает вокруг одних и тех же вещей ↘️

📌Факап №1.
Никто не договорился, кто за что отвечает

😔 Самый популярный сценарий:
одна команда считает, что поле должно заполнять другая команда,
вторая команда считает ровно наоборот.
Итог? Поле пустое, сроки уже горят,
а на созвоне человек десять судорожно пытается понять, чья же это, в конце концов, головная боль.😠

Поэтому на этапе проектирования полезно задавать скучные вопросы:
👉 кто владелец данных?
👉 кто отвечает за их хранение?
👉 а за актуальность кто?
👉 кто исправляет ошибки?
Чем раньше мы расставим все точки над "и", тем меньше потом будет сюрпризов.

📌 Факап №2.
Интеграцию проектируют по счастливому сценарию

😔 Очень часто обсуждается только вариант:
запрос отправился 👉 ответ пришёл 👉 пользователь счастлив.
😔 Но реальная жизнь почему-то любит другие сценарии:

👉 что если сервис вдруг недоступен?
👉 или ответ придёт не сразу, а через полминуты?
👉 а если вдруг статус вернётся совсем не тот, что мы ждали?
👉 что, если пришла пустая структура, хотя должна быть?
👉 или данные вроде есть, но заполнены как-то не полностью?

Именно поэтому один из самых полезных вопросов на обсуждении интеграции:
"а что будет, если всё пойдёт не по плану?"

📌 Факап №3.
Документация не совпадает с реальностью

😔 Любой аналитик хотя бы раз открывал документацию,
видел поле string, а потом получал в него целый массив объектов...😒
😔 Или спека обещала один набор данных, а реальный ответ АПИ принёс ещё двадцать полей сверху.😐
‼️Так что, если есть хоть малейшая возможность, проверяйте методы сами.
Постман в этом плане очень быстро помогает понять, где вы находитесь

📌 Факап №4.
Все считают, что данные всегда будут идеальными

👉 ИНН без ИНН
👉 дата без даты
👉 пустые строки вместо значений
👉 лишние пробелы
👉 неожиданные спецсимволы
👉 дубликаты
Если данные приходят из внешней системы, рано или поздно кто-нибудь обязательно пришлёт что-нибудь интересное.
Вопрос лишь в том, когда это случится)

📌 Факап №5.
Забыли про версионирование

😔 Пока интеграция новая, всё отлично.
Но пройдёт год, появится новая версия метода, а потом ещё одна.
Кто-то решит изменить структуру ответа.
😔Потом начинается археология:
"Ээ, а какой контракт сейчас используется в проде?"
📏📏📏📏📏📏📏📏

👌Поэтому все изменения в АПИ лучше обсуждать сильно заранее и обязательно где-то фиксировать,
иначе однажды можно узнать о новой версии метода прямо из упавших логов,
которые внезапно покраснели.☺️

🌱 А ещё - большинство проблем в интеграциях связаны не с кодом)
Они появляются на этапе, когда команды что-то не договорили, не уточнили или решили проверить потом.
🌱 Вот почему хорошая интеграция начинается совсем не с написания АПИ,
а с кучи, порой неудобных, вопросов.

🤪 Как проводить интервью с пользователями

❌Если дать аналитику документацию, он найдёт ответы.
❌Если дать аналитику доступ к базе, он найдёт ответы.
❌Если дать аналитику логи, он тоже найдёт ответы.
👉 А вот попробуй посадить аналитика напротив пользователя и скажи:
"разберись, как он работает" - тут-то и начинается совсем другая игра.⏳

Ведь пользователи редко говорят все как есть.
А бывает, что и вовсе рассказывают не то, чем занимаются на самом деле.😏

ℹ️Вот спросишь, скажем: "как часто этой функцией пользуетесь?",
а в ответ: "почти каждый день!"
Откроешь потом статистику, а там последний раз человек заходил три месяца назад...
и такие штуки происходят постоянно.
🤩Так что хорошее интервью – это не просто проход по списку вопросов.
Это, по сути, попытка вытянуть наружу, как человек реально себя ведет, что делает.

📌Ошибка №1: спрашивать, что пользователь думает, а не что он делает.

✖️Плохой вопрос: "Вам удобно работать с системой?"
👌Хороший вопрос: "Покажите, как вы выполняли эту задачу в последний раз."

В первом случае человек начнет рассуждать, давать оценку.
Во втором – покажет, что происходит на практике.
А практика, как правило, намного интереснее, чем любые рассуждения..

📌Ошибка №2: самому подсказывать ответы.

⭐Пример диалога:
- Вам было сложно найти эту кнопку?
- Наверное, да.
- А если бы мы перенесли её наверх, стало бы удобнее?
- Наверное, да.
Через пять минут такое интервью превращается в игру, где надо угадать правильный ответ, который ждет аналитик.
Чем меньше подсказок в вопросе, тем лучше. 👀

📌Ошибка №3: говорить больше, чем пользователь.

Парадоксально, но иногда аналитик занимает процентов восемьдесят времени интервью.
Объясняет, уточняет, рассказывает про будущие доработки, делится идеями.
А потом встреча заканчивается, и оказывается, что про пользователя почти ничего нового не узнали.👊

📌Ошибка №4: искать подтверждение своей идеи.

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

📌Ошибка №5: не попросить показать.

Самые полезные фразы на интервью:
"Покажите, пожалуйста"/"А можете продемонстрировать?"/"Как это выглядит в системе?"

😔Потому что между словами пользователя и его реальными действиями иногда лежит целая пропасть.
Любой аналитик хотя бы раз слышал фразу "да тут всё просто".
После чего открывался экран с двадцатью вкладками, тремя Excel-файлами и инструкцией на сорок страниц.

🤩 Именно поэтому хорошие интервью нужны не для того, чтобы узнать, что пользователь думает.
Они нужны, чтобы понять, как человек работает на самом деле,
а это далеко не всегда одно и то же.

📄 Файловые интеграции: старо, но работает

🤩 Многие начинающие аналитики представляют свою работу как проектирование современных систем с REST API, Kafka и т.д.
Кажется, что весь айти мир 🤩 это сплошной поток данных в реальном времени.

🤩 А потом такой специалист попадает на реальный проект
и слышит от коллег:

Значит так, раз в пятнадцать минут мы забираем XML-ку с того FTP-сервера, а после обработки кладем ответ в папку рядом.

И тут наступает легкий шок...😳
😔 Выясняется, что файловые интеграции никуда не делись, их по-прежнему полно везде:
в банках, крупных корпорациях и госсекторах.
😔 И особенно там, где нужно наладить обмен данными между совершенно разными организациями.

🤩Почему это до сих пор живет? Все дело в простоте.
Эта схема настолько элементарна, что может стабильно работать десятилетиями.
Одной стороне нужно просто создать файл, другой его забрать и прочитать.
Не нужно поддерживать постоянное соединение, не нужно переживать, доступна ли вторая система прямо в эту секунду.
👌Принцип "положил и забыл" в определенных условиях работает идеально.

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

🪵 как система должна реагировать на дубликаты файлов?
🪵 можно ли обработать документ, если из нескольких тысяч записей в нем некорректна только одна?
🪵 каким образом подтверждать успешное получение данных или сообщать об ошибках?

🤩 Особое внимание здесь уделяется схеме данных.
Если в REST можно открыть Swagger, быстро дернуть запрос и посмотреть ответ, то здесь весь контракт зашит в структуру файла.
Лишний атрибут, не тот формат даты или какой-то странный символ в строке - и процесс встанет.

🙆‍♂️ Для опытного специалиста файлы ➡️ это не устаревшая технология, а прагматичный инструмент.
В нем нет хайпа или сложной событийной архитектуры, но есть стабильность.

Пока мы рассуждаем о технологиях будущего,
какой-нибудь старый добрый XML-файл прямо сейчас спокойно делает свою работу, даже не зная, что его уже десять лет пытаются отправить на пенсию.