В первой части я рассказал, что такое капсула и зачем упаковывать опыт. В второй части — как мы построили капсульный фреймворк для микросервисов. Если вы не читали предыдущие части, советую начать оттуда.

В этой части я покажу, что происходит, когда к капсуле подключается AI-агент. Почему жёсткая структура капсулы — это именно то, что нужно агенту. И как опыт, упакованный в капсулу, становится опытом, которым может пользоваться машина.

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

В этой части перейдём от теории к практике. Я покажу, как мы создавали собственный капсульный фреймворк для микросервисов, что закладывали в его основу и как он стал ДНК наших проектов.

Всем привет! Меня зовут Сергей, и у меня есть жгучее желание поделиться с вами концепцией разработки через капсулы. Если вы пока не понимаете, что это означает — это нормально. Термин новый, и его определение я как раз дам в этой статье. Я решил ввести понятие «капсула», потому что не нашёл существующего термина с нужным смыслом — пришлось придумать свой.

Статья будет посвящена в основном процессам разработки внутри одной абстрактной компании: их организации и улучшению с помощью нового термина «капсула». Я приведу примеры из своего опыта осознанного применения капсул в разных проектах и процессах. Но прежде чем дать определение самому термину и рассказать, как это работает, важно разобраться в причинах его появления. Поэтому начнём с самого главного — с опыта.

Представьте, что вы работаете в команде над крупным проектом какое-то время. Проект прошел начальный этап и уже работает в продакшн среде. Им пользуются люди, даже можно сказать, что им пользуются много людей и они рассчитывают на ваш продукт, он для них важен. С какого-то момента вдруг вами овладевает беспокойство, что что-то не так. Каждый спринт дается тяжело. Новые задачи вызывают проблемы с внедрением, а после релиза вы ловите один инцидент за другим. Каждый день вы со страхом смотрите в свой месенджер, боясь увидеть очередное сообщение с очередной проблемой, которую нужно срочно решать. Запросы к базе начинают тормозить, важная информация теряться, все валится из рук, контроль над ситуацией утекает как песок сквозь пальцы. Вы начинаете плохо спать, начинают снится кошмары о бесконечных сообщениях в очередях вашего брокера, которые воркеры не способны переварить. Вам снятся сервера, на которых заканчивается CPU и память, потому что сервисы безмерно потребляют ресурсы. Утилизация дисков на серверах с СУБД уже давно под 100%, ведь сервисы что-то постоянно с них читают или пишут. Ошибки, задержки, падения. Вы просыпаетесь.

Node.js — это популярный инструмент для построения клиент-серверных приложений. При правильном использовании, Node.js способен обрабатывать большое количество сетевых запросов, используя всего один поток. Несомненно, сетевой ввод — вывод является одной из сильнейших сторон этой платформы. Казалось бы, что используя Node.js для написания серверного кода приложения, активно использующего различные сетевые протоколы, разработчики должны знать, как эти протоколы работают, но зачастую это не так. Виной тому еще одна сильная сторона Node.js, это его пакетный менеджер NPM, в котором можно найти готовое решение практически под любую задачу. Используя готовые пакеты, мы упрощаем себе жизнь, переиспользуем код (и это правильно), но в то же время скрываем от себя, за ширмой библиотек, суть происходящих процессов. В этой статье мы постараемся разобраться в протоколе WebSocket, реализуя часть спецификации, не используя внешних зависимостей. Добро пожаловать под кат.

Всем привет! В современном мире крайне важна возможность масштабировать приложение по щелчку пальцев, ведь нагрузка на приложение может сильно отличаться в разное время. Наплыв клиентов, которые решили воспользоваться вашим сервисом, может принести как большую прибыль так и убытки. Разбиение приложения на отдельные сервисы решает проблемы с масштабированием, всегда можно добавить инстансов нагруженных сервисов. Это несомненно поможет справиться с нагрузкой и сервис не упадет от нахлынувших на него клиентов. Но микросервисы вместе с неоспоримой пользой, вносят и более сложную структуру приложения, а так же запутанность в их взаимосвязях. Что если даже успешно масштабировав свой сервис, проблемы продолжаются? Время ответа растет и ошибок становится все больше? Как понять, где именно проблема? Ведь каждый запрос к API может порождать за собой цепочку вызовов разных микросервисов, получение данных из нескольких БД и сторонних API. Может это проблема с сетью, или API вашего партнера не справляется с нагрузкой, а может это кеш виноват? В этой статье я постараюсь рассказать, как ответить на эти вопросы и быстро найти точку отказа. Добро пожаловать под кат.

Всем привет! Популярность интернет коммерции постоянно растет, как и доля информатизации всех смежных с торговлей видов деятельности. Вместе с этим растет и сложность обработки информации. Каждый заказ, сделанный клиентом интернет магазина, порождает за собой большое количество интеграций с различными сервисами. Такими сервисами могут быть сервисы обработки платежей, доставки, системы учета и лояльности. Каждый заказ должен быть оплачен, учтен, собран и доставлен, а также доступен для последующего анализа. Эту, и так не простую ситуацию, усложняет и тот факт, что пользователь интернет магазина не хочет долго и мучительно чего-то ждать при оформлении заказа. Отклик от интернет магазина должен быть быстрым, ведь каждая миллисекунда задержки увеличивает шанс потери клиента, а в последствии и прибыли. В этой статье я хочу рассказать про брокер сообщений RabbitMQ и как с его помощью можно организовать процесс обработки заказов используя Node.js и TypeScript. Добро пожаловать под кат.