Или история о том, как 5408 байт обфусцированного JavaScript, прилетающих в HTTP-заголовке, превращаются в свободный доступ к GPT, Claude, Mistral и генерации картинок если построить браузерный манекен на чистом JS.
Недавно на одном сайте пропали превью ссылок в Telegram. Разметка на месте, сайт открывается, ошибок нет, а в логах сервера за десять дней ни одного запроса от Telegram. Это самый неприятный вид поломки: сайт вроде бы работает, а что-то важное тихо сломано. Разбираем, как сделать бесплатный мониторинг WordPress-сайтов на Cloudflare Workers и во что упираешься в лимитах бесплатного тарифа.
Недавно команда Telegram выкатила решение, которое закрывает все эти вопросы разом — нативную платформу Serverless (beta) прямо внутри @BotFather. Теперь запускать серверную логику бота на JavaScript, хранить данные в реляционной БД и раздавать фронтенд для Mini App можно непосредственно в облаке Telegram без собственного сервера.
В этой статье разберём, как устроен tgcloud изнутри, почему его документация идеально заточена под разработку с помощью ИИ-агентов, и посмотрим на реальный кейс: как я поднял на этом стеке игру Wordle (wordslebot) с единым стейтом для чата и Mini App, системой друзей, лобби, мультиплеерными комнатами и внутриигровым чатом.
Можно ли превратить обычный сайт небольшой компании в ИИ-консультанта и уложиться в бесплатные квоты хостинга? На примере показываем, как собрали такого помощника с агентом на платформе Cloudflare.
Внутри — семь этапов: от подготовки базы и сравнения моделей до проверки темы, ограничений расхода и ссылок на разделы сайта. Разбираем реальные ошибки: выдуманные кейсы, пустые ответы и “сортировку на Python” вместо консультации по услугам сайта. Скриншоты, пошаговая инструкция для воссоздания и ссылка на работающий чат.
Я сделал бесплатную проверку сайтов на нарушения 152-ФЗ: вводишь адрес, получаешь список проблем. Первая версия умела ещё кое-что, чего я в неё не закладывал. Подставляешь чужой хост и порт, и по тексту ошибки видно, открыт порт или закрыт. Бесплатный сканер портов для всего интернета, причём запросы идут с адресов Cloudflare.
Это одна из трёх дыр, которые автоматическое ревью нашло в первой версии до выкладки. Ниже про все три, про то, почему такой сервис вообще нельзя ставить рядом со своими серверами, и про слабые места. Одно из них я нашёл и закрыл, пока писал эту статью.
Запись в Notion - и текст на чужом сервере. Задачи в облачном планировщике - данные в чужой аналитике.
Волна локальных LLM показала широкой аудитории, что on-device - это реально. Модель работает, данные не покидают машину. RAG в indexeddb - кто так не делал?
Тот же сдвиг происходит с обычными инструментами. Всё заметнее, что ежемесячная подписка - это аренда софта, которым не владеешь и который нельзя отключить от сети.
Я доделал свои 7 pet-проектов. Все работают целиком в браузере, без сервера, без регистрации, без отправки данных куда-либо. Только локальное хранилище, шифрование на стороне клиента и нативные браузерные API.
Многие смотрят на это спустя рукава, но Google создавал AIStudio не для того, чтобы вы ежедневного пользовались им в качестве основного интерфейса для общения с LLM. Студия была создана с целью дать возможность разработчикам настраивать параметры инференса, тестировать, баловаться. И не нужно быть главным‑по‑aistudio, чтоб это понять — там есть тулинг, граундинг поиска, можно изменить системный промпт. Диалоги сохраняются в виде файлов на гугл диске, чтоб было можно их клонировать, бекапить, итд. Есть отдельная страница с рейт лимитами, с выпуском API токенов. Это — ворота к программному интерфейсу для разработчиков, а не удобный chatgpt‑like веб‑интерфейс.
Каждый, кто пишет на TypeScript хотя бы пару лет, отлично знаком со стандартным DI-сценарием: класс, декоратор @Injectable(), флаг emitDecoratorMetadata в конфиге и рантайм-магия фреймворка. Этот подход казался прорывным в 2015 году, но современный TypeScript ушел далеко вперед. У нас появились мощнейший статический анализ и продвинутый вывод типов, в то время как популярные DI-контейнеры вроде NestJS, InversifyJS или TSyringe будто законсервировались в прошлом.
Слепая приверженность старым паттернам начинает откровенно тормозить индустрию. Из-за legacy-декораторов мы оказываемся заперты в рамках медленного tsc без возможности безболезненно уйти на сверхбыстрые сборщики вроде esbuild или SWC. Наша бизнес-логика намертво заражается инфраструктурными импортами сторонних библиотек, а ошибки в графе зависимостей и скрытые утечки памяти обнаруживаются не на этапе компиляции, а уже в рантайме под нагрузкой на проде.
Но что, если заставить компилятор TypeScript проверять валидность всего графа зависимостей еще до запуска кода? Без декораторов, reflect-metadata, кастомных трансформеров и тяжелой кодогенерации.
В этой статье мы разберем концепцию «экстремальной типизации» на примере InferDI — первого DI-контейнера, где сам граф зависимостей вместе с lifetime-правилами перенесен напрямую в систему типов. Мы поговорим о фундаментальных вещах: почему полный отказ от «удобной» магии аннотаций в пользу 100% ванильного TypeScript — это лучшая инвестиция в архитектуру, безопасность, скорость сборки и долговечность вашего проекта на годы вперед.
Если ваша CMS или CRM умеет отправлять email‑копию о новом заказе на произвольный адрес — этот гайд для вас. InSales, RetailCRM, МойСклад, WooCommerce, Битрикс, самописная система — без разницы. Инфраструктура одна и та же. Ссылка на гитхаб с полным мануалом по установке на русском в конце статьи.
Поводом написать стало то, что неделю назад приложение InSales было удалено из App Store и пуши о заказах пропали сразу. Таким образом мы пропустили несколько заказов, но благо они не сорвались полностью, хотя небольшой неприятный осадок остался.
Первая мысль при поиске решения — n8n или Make. Но зарубежные no‑code платформы сейчас работают в России нестабильно из‑за замедлений и блокировок трафика. Строить критическую бизнес‑инфраструктуру на том, что может лечь в любой момент — плохая идея.
Задача: автономная система, работающая внутри РФ, без постоянного сервера, с доставкой уведомлений в Telegram за секунды. Решение — Yandex Cloud Serverless, т.к он не боится блокировок, имеет очень щедрые лимиты, благодаря чему функция работает полностью бесплатно. К тому же сервис очень гибок в настройке и улучшении.
Расскажу, что получилось, и дам полный гайд по настройке.
Долгое время я пытался научиться слепому десятипальцевому методу печати, но всегда это заканчивалось поражением. Учился на Keybr — на нём освоил английский. Частотный метод, когда ты печатаешь настоящие слова из самых частых букв, мне подошёл. Но столкнулся с тем, что заглавные буквы, пунктуация и цифры спрятаны за кучей настроек. Подумал — зачем это прятать, если можно сделать структурированные этапы и дать чёткий путь прохождения? Так я начал разработку TypeStep — тренажёра слепой печати с частотным методом и этапами прохождения. А теперь — про то, на чём это всё построено и с чем пришлось столкнуться.
Я сделал Telegram-бота, который по короткому фрагменту детского плача (в MVP беру 5 секунд) пытается угадать причину из 6 классов и быстро вернуть ответ. Это не диагностика: бот может ошибаться, а шум и контекст ломают предсказание сильнее, чем хочется.
Здравствуйте, товарищи! Недавно мне понадобилось сделать простой бэкенд для онлайн-песочницы в своем open source проекте. Сейчас для таких задач есть много конструкторов и low-code решений, типа n8n. Но я "по старинке" решил взять serverless с лямбдами, поскольку в позапрошлой компании плотно работал с этим стеком.
Вспоминая тему serverless, я обнаружил, что в русскоязычном пространстве, и на Хабре в частности, почти не освещена одна полезная техника. Пришло время исправить ситуацию и заполнить пробел данной статьей!
Не всегда код должен работать непрерывно. И обидно арендовать целый сервер, когда скрипт работает 10 минут в день. Особенно сервер с большим количеством ОЗУ и CPU.
В этой статье мы расскажем, как запускать скрипты экономически эффективнее, чем на VDS, и как настроить работу кода по расписанию.
Представьте, что вы написали скрипт, разместили его как serverless-функцию и неожиданно получили счёт на 75 000$ из-за самой простой ошибки обработки исключений. Представить страшно, а ведь это реальная история.
У каждого типа IT-проектов есть свои особенности, определяющие где, и как, их лучше размещать. Сегодня мы сравним несколько вариантов хостинга, для простых скриптов как парсеры, боты, API и Web-приложений.
С начала 2020-х начался бурный рост low-code/no-code платформ — технологий, не требующих при разработке написания программного кода. Она опирается на визуальные интерфейсы, конструкторы и готовые модули, которые собираются как конструктор из блоков. Цель платформы zero-apps — доступ к созданию цифровых решений, позволив бизнес-аналитикам, менеджерам проектов, маркетологам и специалистам по продукту воплощать идеи в работающие прототипы и полноценные web-приложения без глубокой технической подготовки на базе Яндекс Облака.
За 10 лет, что существует Serverless‑подход, бессерверные функции стали для многих разработчиков чем‑то привычным и удобным. С их помощью можно быстро написать несколько строк кода для реализации конкретной бизнес‑логики и задеплоить, не думая о развёртывании, настройке и обслуживании инфраструктуры. Нужный код запустится автоматически при срабатывании триггера, как это принято в событийно‑ориентированной архитектуре. Но если таких функций в приложении потребуется очень много — что поможет сохранить нужную скорость работы и другие преимущества Serverless?
Меня зовут Сергей Ненашев, последний год я разрабатываю в Yandex Cloud сервис бессерверных функций Cloud Functions. В нашем облаке с ним можно запускать код в виде функции без создания и обслуживания виртуальных машин.
Пожалуй, важнейший процесс в этом сервисе — это обработка внешнего входящего запроса. Чтобы эта конструкция работала с минимальными задержками, нам понадобилось хорошенько продумать архитектуру обработки запросов и применить пару трюков. Я расскажу, как команда пришла к тем решениям, что работают сейчас, а также покажу, на что обратить внимание самим пользователям, чтобы запрос пробегал по всей инфраструктуре не более 10 мс.
Много было сказано про Serverless в нагрузках без сохранения состояния. Действительно, когда у вас есть контейнеры или функции их легко почти мгновенно масштабировать и нет большой разницы, на какой именно машине это делать.
Но данные имеют очень конкретную привязку к диску, на котором размещены. Что создает немало сложностей к самой концепции бессерверных вычислений.
В этой статье я хочу показать, где бессерверная архитектура может быть применима, и рассмотрю несколько новых, и весьма перспективных решений в этой области, таких как Neon, Warpstream и TiDB.
В последнее время активно занимаюсь разработкой Telegram-бота с использованием Serverless-подхода в Timeweb и Vercel сервисах.
В этом посте я расскажу, как на практике за пару часов реализовал serverless OCR-сервис на AWS, используя AWS Lambda и модель из Amazon Bedrock. Статья ориентирована на опытных AWS-архитекторов, поэтому мы углубимся в архитектуру, покажу код (Terraform для инфраструктуры и Python для Lambda), обсудим масштабирование, ограничения и прикинем стоимость решения в регионе eu-central-1 (Франкфурт).
