Пост-знакомство

Привет! Меня зовут Тимофей, я Senior System Analyst с суммарным опытом в IT около девяти лет. Это мой канал-визитка, который я планирую использовать для развития своего профессионального бренда. Добро пожаловать!

Пара фактов обо мне:
👩‍🎓 Я окончил магистратуру в РГУ нефти и газа по специальности "Автоматизированные системы управления";
💻 Работал бизнес-, системным и fullstack аналитиком в разных доменах: ERP (🖥, 💛 и вот это вот все), немного Fintech, сейчас работаю с Computer Vision 📹 + ML (нынче это модно);
🏆 Когда-то в течение года я лидил небольшую support-команду;
🇩🇪 А ещё некоторое время я жил в Германии (Wie geht es dir?).

В общем, анализировать бизнес-процессы, искать возможности и подходы для автоматизации, проектировать архитектуру — это то, что я люблю, умею, практикую. Я с радостью выявлю, проанализирую и задокументирую 🟦 все ваши тайные желания требования, распилю ваш монолит на микросервисы, спроектирую 🤫 и вообще всю архитектуру приложения, наполню бэклог и заломлю конский прайс. Могу даже что-нибудь набыдлокодить. 🥲

На этом канале я планирую делиться своим профессиональным опытом, рабочими кейсами, образовательными статьями, наблюдениями и мыслями о профессии и в целом рынке труда. Так что если разработка сложных информационных систем в сфере ваших интересов, или если вы планируете погружаться в сферу бизнес-/системного анализа, то здесь для вас найдется много полезного (я надеюсь).
Кстати, ссылка на мой LinkedIn: тык.
Собственно я: @tekhazanov1

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

Так получается, что на текущем проекте частенько приходится подключаться к партнерским да и просто публичным API, и вот, что я думаю, анализируя некоторые API: принципы REST не просто так придуманы. Нет, я, конечно, за гибкость и адаптивность, а не за слепое следование правилам, но полное игнорирование best practice приводит к костылям и велосипедам🩼🚴‍♂️ (экспоненциально разрастающемуся хаосу).
Я не спорю, разработка ПО — процесс нелинейный, но иногда стоит пожертвовать скоростью поставки новой фичи в угоду проработанной архитектуре.

Итак, что довелось повидать (названия эндпоинтов вымышлены, но суть передают):

🚩Эндпоинты-загадки: GET /get_data, POST /process_records. Что за data? Какие records? Пути ничего не говорили о ресурсе. (Это я уж молчу про то, что в названии эндпоинта не принято указывать действие, оно и так обозначено в методе, в данном случае get).
🚩Игнор всех методов, кроме POST: Всё через POST, даже для простейшего получения данных. POST /getUserOrders вместо логичного GET /users/{id}/orders. Да, бывают кейсы, когда использование POST для получения данных можно обосновать. Например, получить данные по сотне-другой заявок, которые так удобно передать через Body, чего не сделаешь в GET. Я все равно при проектировании стараюсь использовать именно GET для получения, а список каких-нибудь id пробую передавать через query (благо нынче можно позволить вызывать очень длинные HTTP-запросы). Тем не менее, для таких исключительных кейсов это вопрос дискуссионный, но не всегда же! 🙈
🚩Коды ошибок, как отдельный вид извращений искусства: В ответе приходил статус 200 OK, а в теле:

{ "status": "error", "code": 47 }

Что за код 47? Это надо было угадать или искать в недоступной документации. Ну или что-то, как на картинке в посте. 🤡

Какие для себя на основе этого я делаю выводы, чтобы не допускать такого? Удивительно, но, видимо, стоит просто следовать принципам REST, которые всем уже оскомину набили.

💚Ресурсы, а не операции. Путь — это существительное, которое отвечает на вопрос «Что?».
Плохо: POST /calculateTotal
Хорошо: GET /cart/{id}/total
💚HTTP-методы — это наши глаголы. Используем их по назначению, это снимает 50% вопросов.
GET /orders (получить)
POST /orders (создать)
PUT /orders/{id} (заменить)
PATCH /orders/{id} (частично обновить)
💚Честные статусы. Если ресурс не найден — это 404, а не 200 с текстовой ошибкой. Если ошибка в данных клиента — 400 с понятным описанием в теле.

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

#REST #API #HTTP #интеграция

Размышления о GraphQL

Сегодня снова об интеграциях: подавляющее большинство интеграций в современных ИТ-продуктах и сервисах реализовано с использованием REST-подхода (мысли про который как раз писал в предыдущем посте). Однако не смотря на популярность этого архитектурного стиля, все равно не получится закрыть глаза на явные недостатки в виде over-fetching и under-fetching (иными словами избыточное и недостаточное извлечение данных), на которые я в том числе планирую сегодня ворчать.
Long Story Short: в очередной раз при проектировании сервиса и проработке его интеграций, когда понадобилось подключиться к другому нашему МС по готовому методу, возникли вот эти раздражающие мысли из серии "Мы сделаем 10 запросов к сервису, чтобы получить две нужные строчки на экран, но при этом получим кучу данных, которые нам, собственно, и не нужны". Так мне и пришла идея сделать ход конем — вкрутить саморезы гаечным ключом "А давайте замутим новую интеграцию через GraphQL 💻 и будем забирать только то, что нам нужно одним запросом!"
GraphQL для меня, как Биткоин. 💰 Он такой стильный, современный, все говорят, что за ним будущее, что вот-вот и фиатные деньги будут заменены им, ведь это удобно, децентрализованно и безопасно, но по факту реально расплатиться им ты можешь только в каком-нибудь Эквадоре, да и то при условии, что тебя после этого не подстрелят. Также и GraphQL — вроде что-то на прогрессивном и современном, но по данным на 2022 год (сорян, актуальнее данные не нашел не искал) подход используется всего-лишь в 0,4% сайтов. Почему так?

Пример полностью вымышленный, но похож на мой кейс (проект связан с парковками и видеонаблюдением):
GET /parkings/{parking_id} — тут получаем информацию по парковке, состоящую из огромного JSONа, 💻 берем отсюда только ID в системе Моспаркинга, все остальные данные нам не нужны;
GET /parkings/{parking_id}/address — тут получаем адрес.

С GraphQL это выглядело бы так:

query {
  parking(id: parking_id) {
    mospark_id
    email
    address {
      city
      street
      building
    }
  }
}

В целом нормально, можно использовать: минимальное количество запросов к API, только необходимый набор данных. 💻 Тем не менее, могут возникнуть следующие сложности:

⚠️Один запрос на GraphQL может породить десятки SQL-запросов, если не использовать DataLoader. В REST эта проблема часто менее выражена, так как с предсказуемыми эндпоинтами он проще в управлении нагрузкой. Не надо одним запросом GraphQL дергать сотню полей с пятью уровнями вложенности... 🙏
⚠️Кэшировать GET-запросы по URL в REST легко. Кэшировать уникальные GraphQL-запросы на уровне HTTP — сложно. Для этого потребуются дополнительные инструменты, тот же DataLoader, например.

Собственно, GraphQL полезен в следующих кейсах 📈:
✅Много разных клиентов (мобильное приложение, веб, smart-TV) с разными потребностями.
✅Данные сильно связаны, и клиенту нужна гибкость в их получении.
✅Скорость разработки на клиенте критически важна (фронтенд может сам собирать свои данные).

Когда лучше выбрать что-то другое 📉:
🚩В случае простого CRUD-сервиса без сложных связей.
🚩Производительность и кэширование — главный приоритет, а команда не готова к сложностям.
🚩Нужны простые и стандартные мониторинг и логирование.

Возвращаясь к кейсу, который натолкнул меня на мысль начать использовать GraphQL на проекте, там в итоге было принято решение использовать REST, но по другим причинам: там планируется миграция сервиса с 🥲 на 💻, поэтому пока отказались от новых подходов.

Зафиналим философским выводом: GraphQL — это не «лучшая версия REST», а принципиально другой инструмент для других задач.

#GRAPHQL #API #HTTP #интеграция

To be honest, для следующего поста у меня была идея порассуждать на тему soft skills, но мой неугомонный кот в очередной раз устроил мне ночное пробуждение своим мяуваньем, поэтому сегодня будет пост про брокеры сообщений. Фото нарушителя приложено в комментарии,👨 а к посту мемчик на тему: Kafka и RabbitMQ. 🐇 Критерии выбора при декомпозиции монолита на примере сервиса обработки медиафайлов.

Как я уже упоминал в каком-то посте, на проекте, в котором я задействован, сейчас вовсю идет распилинг монолита на микросервисы, а заодно часть МС мигрируют с Python 👩‍💻 на Rust💻. Собственно, данный процесс уже давно идет и в рамках инфраструктуры активно используется RabbitMQ, так что есть повод порассуждать, почему именно такой выбор был сделан (к сожалению не мной, я пришел на все готовенькое, так что буду просто умничать на эту тему).
Очевидно, что брокер сообщений выбирается исходя из задач, которые будет выполнять система. В нашем случае мы имеем систему видеонаблюдения и распознавания. Грубо говоря, если ваша ТС оказалась в зоне, просматриваемой камерами, вы будете жестко сфотографированы📸, засняты на видео, а если вы что-то нарушили и дело дойдет до суда, то сурово наказаны как раз эти фоточки окажутся на столе у судьи. 👮‍♀️ На самом деле, в системе много МС и каждый делает что-то свое: сегментирует ТС, распознает ГРЗ, формирует разные отчеты по фиксациям и отправляет их во внешние системы, стримит видео и т.д. Упростим для примера: комплекс снимает фото и передает его какому-нибудь МС в облако, а МС что-нибудь с этим кадром делает (отчет, например) и назовем его, например, Video Analyzer (название вымышлено).

Когда нужно наладить асинхронную передачу данных между микросервисами, первое архитектурное решение — выбор между RabbitMQ и Kafka. Ключевое различие между ними в том, как сообщения попадают к потребителю.

Основное отличие: Push против Pull
✍️RabbitMQ работает по push-модели. Как только сообщение появляется в очереди, брокер немедленно проталкивает его на одного из доступных потребителей.
✍️Apache Kafka использует pull-модель. Потребители сами периодически опрашивают брокера, готовы ли новые сообщения к обработке.

Почему же в моем кейсе RabbitMQ предпочтительнее:
💪Мгновенная доставка (Push). Камера отправляет кадр в RabbitMQ, и брокер сразу же проталкивает его на свободный экземпляр Video Analyzer. Это обеспечивает минимальную задержку между съемкой и началом анализа, что критично для систем реального времени.
💪Балансировка нагрузки из коробки. RabbitMQ автоматически распределяет кадры между всеми работающими экземплярами Video Analyzer. Это не требует дополнительной логики на стороне потребителей.
💪Идеальное соответствие модели «задача-результат». Обработка каждого кадра — это отдельная, атомарная задача. RabbitMQ гарантирует, что каждый кадр будет обработан, а в случае сбоя обработчика будет перенаправлен другому.

Простой пример сообщения, которое можно передать в брокер, чтобы забрать картинку с S3:

{
  "image_path": "s3://camera-bucket/entrance/2023-10-26/cam_01_15-30-00.jpg",
  "camera_id": "cam_entrance_01",
  "timestamp": "2023-10-26T15:30:00Z",
  "analysis_type": "object_detection"
}

А что по Кафке?

Поскольку Kafka имеет pull-модель, микросервис Video Analyzer будет вынужден ее постоянно опрашивать: «Есть ли новые кадры?». Это создает дополнительную нагрузку и может увеличить задержку. Kafka великолепна там, где нужна гарантированная доставка и сохранение потока событий (например, телеметрия или логи), где можно обрабатывать данные пачками. Но для нашего сценария, где важна скорость реакции на одиночное событие, это избыточно.

Как обычно, глубокий вывод в конце:
RabbitMQ (Push) — ваш выбор, когда события требуют немедленной реакции и вы работаете с отдельными, важными задачами. Как в нашем случае с передачей кадров. 🧐
Kafka (Pull) — ваш выбор, когда вы имеете дело с непрерывным потоком данных, который нужно надежно хранить и иметь возможность переигрывать. 😎

#MessageBrokers #Kafka #RabbitMQ #Microservices #Architecture

Каждый раз к концу рабочего дня в офисе у меня на столе собирается вот это 👆 (на фоточке). 😵‍💫
На самом деле, по моему договору на текущем месте у меня фулл-удаленка, даже привязки к конкретной стране нет, что по нынешним временам дорогого стоит. 😎 Тем не менее, пару раз в неделю я езжу в офис: так принято в текущей команде, и я понимаю, почему. Онбординг проходит легче, а погружение в процессы быстрее, взаимодействие между людьми выстраивается лучше, да и вообще, мне кажется, люди друг к другу теплее относятся, когда видят друг друга вживую, а не через фасад аватарок в маттермосте.
Надо сказать, что с начала пандемии я ни разу не работал в гибридном режиме — только удаленка. При этом, вроде как, все получалось: и со стейкхолдерами общаться, и с коллегами взаимодействовать, собственно, и задачи закрывались. Тем не менее, сейчас я часто ловлю себя на том, что часть вопросов просто удобнее обсудить face-to-face. Начинается вот такое: "Ты же в среду будешь в офисе? Ну давай тогда как раз обсудим это/посмотрим то." И вот с одной стороны на среду уже накидано несколько очных встреч, но с другой стороны они проходят продуктивно и наглядно. Особенно, если нужно что-то вместе посмотреть и пощелкать в какой-нибудь системе. Да, конечно, очень не хватает возможности сделать запись экрана во время встречи, чтобы потом отстенографировать ее какой-нибудь нейронкой и иметь уже перед глазам основные тезисы, но в остальном оно все равно удобнее лично общаться.
В целом, конкретно на текущем месте мне мотыляться в офис по кайфу, тут есть ряд перков:
🌟 Мне очень повезло с коллективом: все классные, всякие хиханьки, хаханьки и смехуечки — это святое дело тут;
🌟 Он близко к моему дому;
🌟 Регулярное приятное чувство смены обстановки (возможно это уйдет со временем, но пока есть);
🌟 Мой рабочий день в офисе стоит на 700 рублей дороже, чем удаленный. 🤑 У нас это компенсация за питание, приятный бонусик. Если в день, когда я в офисе, я поел меньше, чем на 700 рублей, то этот день я считаю профицитным. 📈 К сожалению, такого еще не случалось ни разу, так как я очень много жру...
🌟 Бесплатный невкусный кофе. Если бы он еще и вкусным был, я бы вообще спился бы... 🍵
Минусы:
1. Дождь на улице. ⛈

Возможно, оно так комфортно воспринимается мной, так как нет чувства обязаловки, да и по факту получается гибрид. Посему объявляю голосование. Мотаться в офис: стрем или норм? 👇

#работа #гибрид #удаленка #системныйанализ

По ту сторону баррикад требований
Довелось мне тут давеча побывать в роли капризного стейкхолдера, который пока не определился с тем прекрасным будущим, которое он хотел бы видеть. В чем суть: так получилось, что в моей текущей компании я первый системный аналитик, поэтому процесс работы, практики и ритуалы приходится выстраивать с нуля. Собственно, по началу я немного даже провалился между стульев: де-юре я был причислен к архитектурному отряду, по факту работал с продуктовой командой. 🍔
Тем не менее, было принято волевое решение сформировать R&D отряд, в котором в том числе оказался и я (с продуктовой командой продолжаю работать). Так вот мне и было поручено заняться проработкой процесса работы: в том числе поставить задачу на ITSM по настройке проекта в Jira. 👩‍💻 Если в создании пространства в Confluence 🖼️ каких-то сложностей нет, то в случае с Jira нужно точно понимать, что ты хочешь.
Итак, что у меня было для постановки задачи:
☑️ 2 пакета травы, 75 табле...
☑️ Примерное представление, что у нас проект будет разделен на две Канбан-борды (для аналитики и разработки);
☑️ Список необходимых статусов, но без четкого понимания статусной схемы;
☑️ Видение интеграции с доской продуктовой разработки.
В задаче на ITSM команду я честно старался не писать в стиле "деловойте хорошевое плоховое не делойте", но все равно не получилось. Были какие-то слепые пятна, про которые я малодушно думал: "ну, там ребята сами как-нибудь придумают, чтобы красиво было". 🙏

В чем собственно моя проблема? Их две.
1️⃣ Отсутствие четкого видения процесса: как все должно быть в итоге;
2️⃣ Отсутствие знания всех возможностей Jira.

Как все это решилось? Профессионализмом ITSM-команды. Ребята не стали городить что-то от себя, а провели со мной две огромные интервью-сессии часа по полтора для выявления требований, где мы сформулировали в деталях весь процесс, посмотрели возможности Jira, прогнали несколько вариантов процессов и в итоге замутили обалденную двойную борду (а точнее две доски в одном проекте) с проработанным workflow и интеграцией с другим проектом. ✨

Философский вывод (ну как обычно): профессиональное выявление требований — это не просто выслушать хотелки , чтобы задокументировать их. Это еще и помочь стейкхолдеру сформировать видение, которое учитывает баланс между потребностью, рисками, бюджетами и техническими возможностями. Побывав в роли "заказчика" прям чувствуешь это на себе.

#SystemAnalysis #Agile #Scrum #Kanban #Jira #СистемныйАнализ #ITSM #ЛичныйОпыт

Слепые пятна в подробнейшей документации и Client-Side Data Enrichment в микросервисной архитектуре

Я стараюсь очень подробно писать все свои доки. Так, чтобы максимально исключить возможность неоднозначных трактований, вопросы и неопределенности. Тем не менее, бывают случаи, что вопросы все-таки возникают там, где вроде бы все ну очень понятно. ❓ Собственно, про один такой случай я и хочу рассказать. 💖

Преамбула: есть микросервис (назовем его Микросервис1) и БД 📂, которую он обрабатывает, назовем ее, допустим DB лол, в данной БД есть таблица object с полями id (это пусть наш первичный ключ), полем name, ну и всякими прочими полями, которые нам для примера не нужны (изобразил на картинке ER схематичненько). 🖼 У нас тут микросервисная архитектура, вот это вот все, поэтому к DB имеет доступ только Микросервис1 и все данные этой базы мы должны обрабатывать через него. Я же разрабатываю Микросервис2, которому в какой-то момент потребуется поле object.name, чтобы что-нибудь с этим полем сделать (а именно наложить в качестве метаданных на монтируемое Микросервисом2 видео). 🐸

Ну, вроде, все понятно, поэтому переходим к сути:
В спеке у меня описание POST запроса от FE к Микросервису2, body которого по описанию должен выглядеть примерно вот так:

{
    "object_id": 123,
    "object_name": "Какое-то_имя_объекта_тут",
    "request_datetime": "2025-11-03T10:12:31"
...
}

Ну и так далее, всякие поля дальше идут. Пишет мне фронтендер и спрашивает:

"Амиго, а зачем мы тут имя объекта передаем, если у нас есть его id?" ❔

А я смотрю и реально не понимаю, на кой хрен я тут пытаюсь передавать имя, которое правильнее было бы просто по ключу из БД забирать... 🔨 Какой кринж и как я вообще мог так затупить? Я посчитал, что я ошибся, и согласился с разработчиком, что лучше это поле убрать отсюда и забрать на бэкенде, после чего пошел заниматься другими делами. Правда минут через 15 в голову пришла не сразу оформившаяся мысль в формате:

"Так, блэт, минуточку!.." 🌳

Перелистал еще раз спеку и вспомнил, что моя задумка была такая: передать сразу с фронтенда на уровень Микросервиса2 те данные, что нам нужны и уже есть на фронтенде, чтобы избежать большого количества запросов уже со стороны Микросервиса2 к Микросервису1. Например, чтобы получить имя объекта. Поэтому, Андрюха, по коням, у нас труп Client-Side Data Enrichment! 😁 Мы передаем избыточные данные с FE и, возможно, дублируем их на уровне БД микросервиса для того, чтобы уменьшить количество запросов между нашими сервисами. (Имя объекта в запрос вернули, все хорошо).

К чему я все это? К тому, что вся эта ситуация случилась через 5 дней после того, как я закончил писать эту спеку. Вот так мало времени потребовалось мне (автору доки, если что), чтобы какие-то нюансы просто вывалились из головы.

Философское завершение: лучше больше документации, чем меньше документации. Все классные идеи будут либо задокументированы, либо забыты, потому что у всех у нас место в голове до конца жизни уже занято чит-кодами для гта, а для всего остального есть Confluence. 🖼️ AEZAKMI

#интеграция #API #REST #HTTP #системныйанализ #json

Роль системного аналитика в проектах с Computer Vision и Machine Learning

Если смотреть в целом, то задачи системного (либо фуллстак) аналитика в проекте с CV+ML не сильно отличаются от выполняемых в других доменах: тот же сбор, валидация и документирование требований, разработка спецификаций, а для тех, кто "постарше" — проектирование архитектуры, ну и дальше опционально могут добавляться user acceptance testing, обучение ключевых пользователей, функциональное тестирование, онбординг юнцов, организация и проведение корпоративов и вообще все, что можно придумать. 👨‍💻 Трактовать эту роль в разных компаниях могут по-разному: например, на текущем проекте мне пришлось выполнить несколько PM-задач в процессе формирования нового R&D-отряда (в общем-то, проработать рабочие процессы и организовать интеграцию с продуктовой командой, к которой я все еще на 50% принадлежу). 😎
Тем не менее, каждый домен имеет свои особенности. Если сравнивать ML с доменом ERP, в котором у меня есть достаточно большой опыт, то можно заметить, что основное отличие: требования в ERP в основном четко формализуемы и детерминированы ("сделайте кнопку, чтобы у меня проводки вот по этому счету бахались"), 📞 в то время как при работе с распознаванием всяких штук на видео всегда имеется высокая степень неопределенности и даже функциональные требования могут быть завязаны на метрики, где метрика — измеримое Acceptance Criteria:

"Котиньки на фотографии должны сегментироваться с точностью 95%". 😿

Что это добавляет в мою работу, как системного аналитика? Проведение исследований, от которых будет зависеть дальнейшее движение продукта (не даром же у я на 50% в R&D-отряде). Важно отметить, что я даже близко не ML-специалист, но я прихожу к ним с конкретным запросом: "Есть гипотеза, надо проверить". Для примера рассмотрим мой недавний кейс.

Сектор "Кейс" на барабане
Есть ML-ка, которая сегментирует и распознает дорожные знаки, по знакам, соответственно, можно определить правонарушение, в размеченной вручную зоне на кадре. Бывает так, что знаки к камере повернуты "спиной" и тогда такой кадр не получится использовать в суде. При разметке зон действия знака возникла потребность помечать такие знаки, развернутые к камере. Однако бывают ситуации, когда знак развернут к камере углом, при котором человеческий глаз может понять, что именно за знак, а вот ML — под вопросом. 📹 Нужно было определить, требуется ли придумывать отдельный "статус" для таких сцен, а мне для этого надо было понять, в какой момент (при каком угле поворота) ML перестает распознавать знак и можно ли (нужно ли?) как-то дообучить модель. С запросом на такое исследование я и пошел к ML-команде. После чего моей задачей было провалидировать результаты исследования с требованиями стейкхолдеров принять решение: вводим "промежуточный" статус или нет.

Мораль: в любой сфере есть своя специфика и нюансы, поэтому в первую очередь нужно качать софт-скиллы, но это не точно.

#системныйанализ #ML #DL #AI #CV #computervision #machinelearning

Short Polling vs Long Polling: донимать пустыми запросами или ждать у моря погоды

Не так давно писал спеку по фиче, которая предполагает передачу данных в режиме реального времени. Не вдаваясь в детали, это разработка микросервиса, который определенным образом монтирует видео и было требование того, чтобы на UI в режиме реального времени видеть статус обработки. 🎬
Изначально для этой цели я предполагал использовать WebSocket: открывать канал связи и получать сообщения напрямую с сервера, однако после обсуждения с архитектурной командой было принято решение, что держать открытыми соединения по каждой заявке на монтаж видео лишь для того, чтобы красиво рисовать полоску загрузки на экране... Охренеть как Немного расточительно. 👌 Поэтому про WebSocket пост будет как-нибудь потом, а сегодня мы поговорим про Polling.

Polling — это в некотором смысле имитация обмена данными в режиме real-time, можно сказать в режиме псевдо-реального времени. Мы не передаем сообщение напрямую с сервера на клиент, клиент запрашивает данные с сервера, но делает он это автоматически с заданной регулярностью. Есть две концепции: Short Polling и Long Polling.

Short Polling — клиент с заданным интервалом (например, каждые 2 секунды) отправляет на сервер запрос по схеме «Есть ли что-нибудь новое?». Сервер всегда сразу отвечает — либо с новыми данными, либо с пустым ответом. Представим себе ребенка в машине, который с интервалом отправляет запрос спрашивает маму за рулем:

"Мы уже приехали? Мы уже приехали?"

Он будет спрашивать это вне зависимости от того, молчит ли мама или уже рявкнула на него:

"ЕЩЕ НЕТ!" 💥

Long Polling — Клиент отправляет запрос, сервер не отвечает сразу, а «замораживает» запрос до тех пор, пока не произойдет нужное событие ИЛИ не истечет таймаут (например, 30 секунд). Как только событие происходит, сервер немедленно отправляет ответ клиенту. Клиент, получив ответ, тут же отправляет следующий запрос. По аналогии с предыдущим примером, это ребенок, случайно хлебнувший утром батиного чая с коньяком и поэтому он задает вопрос бате за рулем и спокойно ждет ответа, пока на стороне сервера таймаут:

"Сколько времени нам еще ехать?"

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

Философское завершение: выбор между подходами — это классический компромисс между простотой и эффективностью.

P.S. Современными альтернативами для обоих подходов являются WebSocket (для двусторонней постоянной связи), его мы уже упоминали сегодня, Server-Sent Events (SSE) (для потоковой передачи данных от сервера к клиенту), gRPC Streaming и некоторые другие технологии, но везде есть свои нюансы и их мы обсудим в другой раз. 🔗

#системныйанализ #Архитектура #WebDevelopment #websocket #HTTP #интеграции