---

## Как я считал

Два источника.

**hh.ru.** Только совпадения в названиях вакансий. Без поиска по описанию — там слишком много шума. Пятнадцать запросов: Python, Java, Go, PHP, Node.js, C# — плюс их комбинации с fullstack и React. Фильтр: вся РФ, зарплата любая.

**Хабр Карьера.** 43 716 анкет, июль 2026. Медианы, а не средние — чтобы пара зарплат из Яндекса не перекосила картину.

Даты: 14–20 июля 2026. Всё руками. Без скриптов.

Что нельзя гарантировать:

Поиск по заголовкам режет абсолютные цифры. Вакансия «Senior разработчик» без языка в названии — мимо выборки. Но пропорции держиЎ смещение одно и то для всех языков.

Это срез недели. Не годовой тренд.

Закрытый рынок (внутрянка, рекомендации) не виден. Совсем.

Регионы: Москва и Ульяновск — разные галактики. Мои цифры — среднее по стране, а не по столице.

И всё же. Для карьерного решения точности достаточно.

---

## Общий рынок: Python — 519. Но это ловушка

Беру все бэкенд-вакансии. Без фильтрации. Грубая масса:

> 📊 **[ВСТАВИТЬ КАРТИНКУ: horiz_bar.png]**

- Python — 519

- Java — 468

- C#/.NET — 227

- PHP — 207

- Go — 141

- Node.js — 62

- TypeScript (бэкенд) — 53

- Ruby — 15

Python вдвое опережает C#. Картинка ясная?

Нет.

Я открыл эти 519 вакансий. Добрая половина — Data Science. Нейросети. ML. Автоматизация. Python-разработчик в банке может не писать API вообще — он обучает скоринговые модели. К fullstack это имеет слабое отношение.

Сырые цифры врут. Красиво врут — но врут. Нужна другая выборка.

Теперь Node.js и TypeScript. Если считать их одним (TypeScript-бэкенд — NestJS или Next.js, технически Node.js), вместе — 115. Третье место, сразу за Python и Java. По-моему, так честнее. Но в таблицах ниже я их разделяю — для прозрачности.

Go — 141. Много для 15-летнего.

PHP — 207. Язык, который «умер» в 2012. В 2015. В 2018. В 2020. 207 вакансий. Никак не добьют.

Ruby — 15.

---

## Fullstack-срез: PHP на первом месте. Я перепроверил трижды

Дальше — фильтрую. Только вакансии, где в заголовке или первом абзаце чётко: «фронтенд + бэкенд». Пришлось вручную просмотреть около 200 штук. Некоторые заголовки врут: написано «Fullstack Developer», внутри — чистый бэкенд.

> 📊 **[ВСТАВИТЬ КАРТИНКУ: fullstack_bar.png]**

- PHP — 30

- Python — 29

- Java — 28

- C#/.NET — 21

- Node.js — 15

- TypeScript — 10

- Go — 2

- Ruby — 1

PHP.

На первом месте.

Я не поверил. Пересчитал. Ещё раз. Цифра честная.

Только вот интерпретация. PHP вырвался не потому, что это лучший язык для веба — а потому что Laravel-экосистема исторически fullstack. Фреймворк даёт бэкенд и Blade-шаблоны из коробки. В вакансиях на Laravel ищут одного человека: база, API, фронт — всё он. Это артефакт экосистемы. Не сигнал «беги учить PHP».

Node.js + TypeScript — 25. Второе место. Я ждал меньше. Думал, fullstack занят PHP и Java, а Node.js где-то в нише. Ошибся.

Go — две вакансии на всю страну.

Две.

Не случайность. Go проектировали для микросервисов, не для fullstack. Искать fullstack на Go — как спорткар с кузовом универсал. Можно, но зачем.

### Несколько цифр без прикрас

- Fullstack-вакансий в выборке: 330

- Удалёнка: 190 (58%)

- Senior: 61, Middle: 24

- hh.индекс: 8,3 — конкуренция

- Динамика: вакансий +8%, резюме −2%

61 senior, 24 middle. В 2,5 раза.

Fullstack — не входная точка в IT. Сначала стань кем-то одним. Потом расширяйся. Рынок ждёт опытных, а middle-позиции подбирает по остаточному принципу.

---

## React + бэкенд: график, ради которого я это затеял

Главный вопрос. Какие бэкенды реально ищут в паре с React? Не «упомянут где-то в глубине требований» — прямо в заголовке или первом абзаце:

> 📊 **[ВСТАВИТЬ КАРТИНКУ: react_combos.png]**

- React + Node.js — 16

- React + PHP — 9

- React + Python — 8

- React + Java — 6

- React + .NET — 5

- React + Go — 1

16 против 9. Node.js отрывается почти вдвое.

И вот что интересно. На общем рынке Node.js — скромный середняк: 62 вакансии. В fullstack-нише — третье-четвёртое место. А в связке с React — уверенное первое.

Не самый массовый бэкенд вообще. Но для React-фронтендера — самый частый выбор нанимателя.

Почему? Четыре причины, которые, по-моему, не случаются сами собой:

**Один язык.** TypeScript на клиенте и на сервере. Типы кочуют туда-сюда без переписывания. DTO описал один раз — работает везде.

**Next.js размывает границу.** API routes, Server Components, Server Actions. Разработчик на Next.js пишет бэкенд, часто не замечая.

**NestJS — когда Next.js маловато.** Модульная архитектура, DI, guards, interceptors. Enterprise-уровень на знакомом TypeScript.

**Общий тулинг.** Zod для валидации, date-fns для дат, shared-библиотеки в монорепе. Никакого дублирования.

React + PHP (9 штук) — обычно Laravel на бэке, React как админка или SPA. Работает. Особенно в e-commerce.

React + Go (1 штука).

Одна.

Кто-нибудь вообще видел такую вакансию вживую? Отпишитесь, мне правда интересно, что за проект.

---

## Деньги: где самый толстый скачок

Хабр Карьера, 43 716 анкет. Медианы.

> 📊 **[ВСТАВИТЬ КАРТИНКУ: salaries.png]**

- Intern — 66 000 ₽

- Junior — 95 000 ₽

- Middle — 177 000 ₽

- Senior — 303 000 ₽

- Lead — 378 000 ₽

Ступеньки: Junior → Middle — плюс 82 тысячи. Middle → Senior — плюс 126 тысяч. Senior → Lead — плюс 75 тысяч.

Самый крутой подъём — между middle и senior. Рынок платит за глубину. Fullstack-middle, который «всё понемногу», стоит сильно дешевле fullstack-senior, который глубоко знает оба направления.

Что за кадром:

Разброс внутри грейдов — пропасть. Senior fullstack в региональной веб-студии и senior fullstack в финтехе живут в разных финансовых измерениях.

Хабр Карьера смещена вверх. Те, кто получает мало, реже заполняют анкеты.

Зарплаты по языкам — за регистрацией. Я не знаю, получает ли PHP-senior столько же, сколько Node.js-senior. Подозреваю, что нет. Доказательств у меня нет.

---

## Удалёнка: 190 из 330

190 fullstack-вакансий из 330 — удалённые.

Я в Ульяновске. Ближайшие офисы крупных IT — Казань, Самара. С удалёнкой это не проблема: работаешь на Москву или Питер из квартиры с видом на Волгу.

Деталь: большинство удалённых fullstack-позиций — аутсорсинг и стартапы. Enterprise осторожничает. Банки. Телеком. Им всё ещё нужен офис. Хотите Java в банке — готовьтесь к гибриду как минимум.

---

## Что я выбрал

Node.js + NestJS + TypeScript.

Не «потому что модно». Пять вещей, которые перевесили:

**Язык один.** Пишу на TypeScript больше пяти лет. Декоратор `@controller()` в NestJS — продолжение того, что знаю. Не прыжок в другую вселенную.

**16 против 1.** React + Node.js — 16 вакансий, React + Go — одна. Работодатель, которому нужен fullstack на React, ждёт Node.js. Мне не надо его переубеждать.

**Потолок далеко.** Простой CRUD на NestJS — за вечер. Дальше — CQRS, event-driven, микросервисы на Kafka/NATS. Есть куда расти.

**Next.js как трамплин.** Server Actions и API Routes — это бэкенд, просто в рамках одного фреймворка. Переход к NestJS — структурирование тех же концепций.

**Одна кодовая база.** Типы, валидация, утилиты живут в одном месте. Без дублирования.

Что через год-два? Не знаю. Может, вторым языком возьму Python + FastAPI — мост в AI/ML-проекты. Может, останусь в Node.js и пойду в ширину: базы данных, инфраструктура, девопс.

Посмотрим.

---

## Если примерять к себе

Ты React/TypeScript-фронтендер? **Node.js, NestJS.** Язык знаешь, рынок подтверждает, вход плавный.

Ты в Data Science / ML? **Python, FastAPI.** Строить веб вокруг ML-моделей — редкая комбинация. Только учти: вакансий меньше, чем в чистом вебе.

Ты в enterprise или планируешь? **Java / C#.** Стабильно. Дорого. Порог входа высокий, экосистема тяжёлая.

Любишь highload и инфраструктуру? **Go.** Fullstack-позиций почти нет. Но как чистый бэкенд — мощно.

Нужна работа прямо сейчас? **PHP, Laravel.** 30 fullstack-вакансий — больше всех. Только готовься к культурной адаптации после TypeScript.

---

Четыре вещи, которые остались после подсчётов.

Node.js — не самый большой рынок. Но для React-фронтендера — точка входа с наименьшим сопротивлением. 16 против 1. Не погрешность.

Fullstack — не старт. 61 senior-вакансия, 24 middle. Сначала глубина. Потом ширина.

Один язык на клиенте и сервере — не «удобно». Это скорость. Меньше ошибок, общий тулинг, никаких «забыл обновить типы после смены API».

Цифры — не догма. Срез июля 2026. Через полгода пересчитаю — и не поручусь, что картина не изменится.

Пишите в комментариях, какой бэкенд выбрали вы. И главное — почему. Реальный опыт интереснее любых цифр.

А если кто-то видел fullstack на Go вживую — маякните. Мне правда интересно.

---

*Данные: hh.ru и Хабр Карьера, 14–20 июля 2026, РФ. Поиск по заголовкам — абсолютные цифры занижены, пропорции репрезентативны. Детальные зарплаты по языкам — за регистрацией, не включены. Региональные перекосы возможны.*

Где словил

У меня cron каждые 6 часов запускает функцию: проверить, есть ли пост за сегодня, если нет - сгенерировать, отправить в TG-каналы и в VK. Между двумя репликами на хостинге координация через advisory lock на номер UTC-дня. Учебниковый паттерн. Плюс отдельная retry-функция, которая досылает посты, не ушедшие в каналы с прошлого тика.

И вдруг утром обнаруживаю: retry пятый день подряд логирует одно и то же:

> [blog] retry sweep skipped (lock not acquired)

> [blog] retry sweep skipped (lock not acquired)

Retry-lock висит залоченный кем-то - взять его никто не может, retry никогда не запускается. А посты в каналы не идут. И хвост постов с "channel_posted_at IS NULL" тем временем растёт.

Первое подозрение - lock и unlock на разных клиентах

Перечитал PostgreSQL-доку про Explicit Locking. По смыслу: session-level advisory lock привязан к конкретному соединению и держится до явного освобождения или до конца сессии. Если взял на одном клиенте - отпускать нужно с того же. У меня же везде было "pool().query(...)", а "node-postgres" "pool.query" берёт первое доступное соединение из пула. Между lock и unlock пул мог отдать разные клиенты.

Тут я и налажал. Думал, pool сам разрулит сессионную привязку - он же с обычными запросами разруливает. (Нет).

Фикс - пинить один клиент через всю операцию:

> // retryKey = что-то стабильное на день, чтобы лок был общий

> const client = await pool().connect();

> try {

> const acq = (await client.query(

> 'SELECT pg_try_advisory_lock($1) AS acquired',

> [retryKey],

> )).rows[0]?.acquired;

> if (acq) {

> try {

> await retryTodayChannelPosts();

> } finally {

> await client.query('SELECT pg_advisory_unlock($1)', [retryKey]);

> }

> }

> } finally {

> client.release();

> }

"pool.connect()" отдаёт один клиент, в "finally" возвращаем в пул. Lock и unlock теперь гарантированно через одно соединение. Деплоил с уверенностью, что разобрался.

Это работало два дня.

Второе попадание - Neon обрывает TCP у pinned-клиента

Просыпаюсь утром на третий день - в логах опять то же:

> [blog] retry sweep skipped (lock not acquired)

Снова. Дошло. Между "pg_try_advisory_lock" и "pg_advisory_unlock" у меня внутри блока шёл retry с TG/VK API-вызовами, это десятки секунд. Что происходит за это время:

1. Я взял клиент A через "pool.connect()".

2. Сделал "pg_try_advisory_lock" на A, получил "true".

3. Начал делать retry, дёргаю TG/VK API. Обычно 30-60 секунд, но иногда залипает на 60-120, если TG отвечает медленно. Пока я в API, на клиенте A никто не выполняет SQL. Соединение idle.

4. Neon - serverless: compute-узлы суспендятся после idle (на Free-тарифе через 5 минут), плюс свои таймауты у proxy-слоя между клиентом и backend-ом. В моём кейсе proxy успевал убить сокет раньше, чем срабатывал compute-suspend - и в особо медленные retry-сеансы unlock уже ехал в мёртвое соединение.

5. Возвращаюсь к коду, пытаюсь сделать "pg_advisory_unlock" через клиент A.

6. node-postgres видит, что underlying socket мёртв: клиент A на самом деле труп, "client.query" падает с "Connection terminated unexpectedly". Сам по себе клиент не переподключится - просто мёртв, пул его выбросит при "release()".

7. Unlock в принципе не выполнился. Старая backend-сессия с локом - на сервере она пока ещё "жива" в смысле, что её процесс выполняется. С её точки зрения TCP клиента просто отвалился, но backend не завершается моментально.

8. В обычном Postgres зазор "TCP пропал -> backend это понял -> сессия закрылась" зависит от tcp_keepalive: при активности это секунды, на дефолтных Linux-настройках без активности backend может узнать о клиенте через часы. В Neon ещё веселее: между моим клиентом и реальным backend-ом стоит proxy-слой со своими таймаутами. Плюс backend может быть suspended (cold compute) и узнаёт о моей смерти только когда его поднимут обратно. Это могут быть минуты или дольше. Всё это время "pg_try_advisory_lock" для остальных возвращает "false".

Я тогда офигел. Unlock не сработал, лок болтается на сервере без хозяина, реплики приходят, видят "false", разворачиваются. И так всё новые сутки. Никто не может зайти.

Локально Postgres такого не делает - он не serverless, idle-сессии висят сколько угодно. В тестах и подавно: моки соединений не разрывают, CI зелёный. А на проде стабильно ловит раз в 2-3 дня.

Я попробовал keepalive - пинговать клиент "SELECT 1" каждые 10 секунд, чтобы не ушёл в idle. Это снизило частоту до "раз в неделю", но не убрало корень. На любой network blip - то же самое.

Что сработало

Перевести retry на row-level locks через "FOR UPDATE SKIP LOCKED" - вообще без advisory locks.

Логика retry была: "найди в БД сегодняшние посты с "channel_posted_at IS NULL", для каждого попробуй послать, если успешно - проставь дату". Это же ровно то, что Postgres умеет нативно через "FOR UPDATE SKIP LOCKED".

> const client = await pool().connect();

> try {

> while (true) {

> await client.query('BEGIN');

> // в боевом коде ещё фильтр slug LIKE 'YYYY-MM-DD-%' под сегодняшние, опускаю для простоты

> const res = await client.query(

> `SELECT slug, title, content_md, lang FROM blog_posts

> WHERE published = TRUE AND channel_posted_at IS NULL

> ORDER BY created_at LIMIT 1

> FOR UPDATE SKIP LOCKED`,

> );

> if (res.rowCount === 0) {

> await client.query('COMMIT');

> return;

> }

> const post = res.rows[0];

> try {

> const { channelOk } = await publishToChannel(post);

> if (channelOk) {

> await client.query(

> 'UPDATE blog_posts SET channel_posted_at = NOW() WHERE slug = $1',

> [post.slug],

> );

> await client.query('COMMIT');

> } else {

> await client.query('ROLLBACK');

> return; // bail на первой ошибке, не ddos-им сломанный API

> }

> } catch (err) {

> try { await client.query('ROLLBACK'); } catch {}

> return;

> }

> }

> } finally {

> client.release();

> }

Что меняется. Лок выдаётся не сессии, а строке. "FOR UPDATE SKIP LOCKED" захватывает первую незаблокированную, остальные потоки её пропускают и идут к следующей. Если транзакция коммитится - лок отпускается, дата стоит. Если роллбэчится (упали или TG ответил ошибкой) - лок отпускается, дата остаётся "NULL", на следующем тике другая реплика возьмёт ту же строку.

И главное: если коннект умер прямо в середине транзакции, Postgres сам делает rollback на серверной стороне и отпускает все локи в этой транзакции. Транзакционный лок не может остаться "потерянным" как advisory: TCP-сброс, idle-timeout, suspended compute - всё это Postgres обрабатывает через штатный transaction abortion. Гарантирует это сама архитектура движка, не настройки.

Если две реплики одновременно начали retry - они просто будут последовательно брать разные строки благодаря "SKIP LOCKED". На уровне нагрузки безразлично, потому что в день максимум 1-3 поста попадают в retry.

Деплоил, четыре дня тишины. Пока нормас.

Итого

Если у вас в коде стоит "pg_advisory_lock" на serverless Postgres - сегодня хороший день пройти по всем местам и спросить себя: а что тут координируется на самом деле? Часто оказывается, что session-lock не нужен вовсе - хватает "INSERT ... ON CONFLICT" или сравнения состояния. В остальных случаях его можно заменить на "FOR UPDATE SKIP LOCKED" под конкретные строки.

Те случаи, когда session-lock действительно нужен - это long-running worker, который держит соединение всю свою жизнь, не отпуская его в idle. В serverless такого зверя нет.

Что бесило больше всего - баг проявлялся раз в 2-3 дня и локально не воспроизводился вообще. Тесты зелёные, CI зелёный. На проде тлеет. Узнавал глубже только когда читатель в комментариях писал «а где сегодняшний пост». Не лучший способ узнавать.

#postgres #neon #nodejs #грабли

Минимальное воспроизведение

Создаём свежий аккаунт через "createAccount" (он сразу выдаёт "access_token"), кидаем через "createPage" контент разного размера:

const para = 'Тестовый абзац с нормальным текстом. ';

let md = '';

while (md.length < kbTarget * 1024) md += para + '\n\n';

const content = md.split('\n\n').filter(Boolean).map(

p => ({ tag: 'p', children: [p] })

);

const res = await fetch('https://api.telegra.ph/createPage', {

method: 'POST',

headers: { 'Content-Type': 'application/json' },

body: JSON.stringify({ access_token, title: `${kbTarget} KB`, content }),

});

Прогнал от 5 до 40 КБ с паузой полторы секунды между вызовами, чтобы исключить rate-limit. Что вышло.

5 КБ исходного markdown - это после "JSON.stringify" 8 581 символ, по UTF-8 примерно 13 600 байт. Прошло. 10 КБ markdown - 17 096 символов JSON, около 27 200 байт. Тоже прошло. 20 КБ - 34 191 символов JSON, около 54 400 байт - "CONTENT_TOO_BIG". 30 и 40 КБ markdown упираются ровно в ту же стену.

Реальный потолок где-то между 10 и 20 КБ исходного markdown. Не 64, как в документации, и даже не близко.

Пробовал отправлять через "application/x-www-form-urlencoded" вместо JSON - поведение идентично, ошибка на тех же порогах. Envelope добавляет 200-300 байт, разница до обещанных 64 не заполняется. Скорее всего, Telegraph внутри парсит payload в свою структуру "Node" и меряет лимит уже после парсинга, где она пухнет за счёт служебных полей. Но это домыслы, проверить нечем.

Почему русский язык упирается раньше английского

Это вторая половина бага. В JavaScript длина строки считается в UTF-16 code units, и "String.prototype.length" для кириллической буквы вернёт 1, как и для латинской. А вот в HTTP-теле строка едет в UTF-8, и там кириллический символ занимает 2 байта на букву. Получается, при одинаковом "length" русский текст по сети ровно в два раза тяжелее английского.

Если Telegraph меряет лимит по байтам после кодирования (это правдоподобная версия), русский контент упирается в потолок где-то на 40-50% быстрее. EN-переводы у меня делает Gemini Flash Lite, они на 30-40% короче по символам, и на все 50% - по байтам. Большой пост в RU даёт 60-80 КБ, его перевод 20-30 КБ. Перевод помещается в зелёную зону, оригинал нет. Вот вам и «на одном языке работает, на другом нет», хотя код между ними общий.

Налажал я именно тут: думал, что байтовый лимит и символьный - это одно и то же. Получил по голове.

Как обойти

Резать markdown под безопасный размер и ставить маркер «полный текст на сайте». Эмпирическая зелёная зона - 18 КБ исходного markdown:

const TELEGRAPH_SAFE_MD_BYTES = 18 * 1024;

function truncateMarkdownAtBoundary(md, maxBytes, lang) {

if (Buffer.byteLength(md, 'utf8') <= maxBytes) {

return { md, truncated: false };

}

let cut = md;

while (Buffer.byteLength(cut, 'utf8') > maxBytes) {

cut = cut.slice(0, Math.floor(cut.length * 0.9));

}

// По возможности режем по границе абзаца, а не посреди слова

const lastBreak = cut.lastIndexOf('\n\n');

if (lastBreak > cut.length * 0.5) cut = cut.slice(0, lastBreak);

const note = lang === 'en'

? '\n\n\_Article truncated for Telegraph. Read full version on the site.\_'

: '\n\n\_Статья сокращена для Telegraph. Полный текст на сайте.\_';

return { md: cut + note, truncated: true };

}

Две детали, на которых легко обжечься.

Цикл режет по длине строки, а не по байтовому индексу. Если бы я сразу резал по целевому байт-индексу, мог бы попасть в середину кириллического двухбайтового символа. Получилась бы невалидная UTF-8 последовательность, и Telegraph такой payload отбрасывает без объяснений. Срез через "String.prototype.slice" по длине гарантирует валидную границу для BMP-символов, куда попадает кириллица.

Шаг 10% на первый взгляд жадноват, но на реальных входах цикл обычно укладывается в 1-2 итерации. На очень коротких текстах работает ранний return.

Поверх этого ставлю retry: если 18 КБ всё равно не прошло (бывает, если в тексте много ссылок - каждая "[text](url)" это плюс 30-50 байт после сериализации), уменьшаю лимит на 40% и пробую ещё раз. Максимум три попытки. Если всё ушло в потолок, публикую без Telegraph-ссылки, в канале остаётся ссылка только на сайт.

Что забрать с собой

Документированные 64 КБ у Telegraph - не верхняя граница, не нижняя, вообще не граница. Эмпирическое число на апрель 2026 - 17-18 КБ исходного markdown. Если они подкрутят свой внутренний лимит, придётся подкручивать и у вас. Сервис существует с 2016, документация обновлялась, кажется, тогда же.

Если у вас пайплайн «генерируем контент - публикуем в Telegraph для OG-карточки - потом ссылка в TG-канал», и в логах хоть раз мелькало "CONTENT_TOO_BIG", - скорее всего, RU-публикация у вас молча отваливается на длинных постах. Загляните в логи, там может быть приятный сюрприз.

И наконец общее. UTF-8 байты и UTF-16 code units - разные вещи. Если интеграция живёт на байтовом лимите, считать надо через "Buffer.byteLength", не через "length". Касается и баз, и транспортного слоя, и rate-лимитов. С токенами LLM ситуация ещё веселее, там для кириллицы вообще другие правила, чем для латиницы, и единственный способ не промахнуться - прогонять корпус на всех языках, которые у вас в проде.

Здесь можно нажать на видео и его посмотреть, здесь есть категории, здесь есть переход к профилю и... Вроде пока всё. Далее планирую добавить Sidebar, как в YouTube, в левой части списка видео.

Да, тут можно подписываться/отписываться, просматривать записи пользователя.

Надо постараться представить адекватную платформу для свободного хоста видео пользователям

Следите за разработкой на моём канале в Пикабу :>

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

Буду рад поддержке:)

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

Я специально взял такую небизнесовую тему, в которой мне не придется конкурировать с серьезными компаниями, это всё-таки проект для души.

Стек и детали реализации

Калькулятор астрологических расчетов

Для начала сделал сервер астрологических расчетов на базе швейцарских эфемерид.

Под капотом Python с FastAPI. Хотел было срезать углы и взять что-то готовое, нашел kerykeion и ещё пару похожих проектов, но какое-то оно всё оказалось несерьезное, и я решил делать сам. Результат выложил на github (nocturna-calculations) и даже развернул на отдельном сервере (Nocturna Calculations Swagger). Кому нужен API ключ поиграться, пишите)

Генератор астрологических карт

Фронтенд решил делать на React, и быстро выяснил, что нарисовать пристойную натальную карту - это задача со звёздочкой для нейросетей.

Пришлось пилить отдельную библиотеку для визуализации натальных карт в SVG.

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

Эту библиотеку я тоже выложил в open source (nocturna-wheel), и даже опубликовал в npm, чисто по приколу (npm install @eaprelsky/nocturna-wheel). Покрутить демо можно тут: https://demo.wheel.nocturna.ru/.

Отказ от фронтенда и микросервис генерации карт

Закончив с библиотекой, я продолжил было делать веб-морду на React, но потом решил, что начать нужно с чего-то попроще и сделал телеграм-бота. Понятно, что для этого я тоже выбрал Python.

Тут оказалось, что отобразить натальную карту, нарисованную в React, не так просто. Можно было, конечно, портировать уже написанную библиотеку на Python и поддерживать две кодовые базы, но мне этот вариант не понравился.

Так что пришлось поднимать отдельный микросервис для генерации изображений. Бэкенд на Node.js поднимает Puppeteer (браузер без GUI), рендерит SVG, делает скриншот и отдает картинку по API. ("Микросервисы, архитектура средней полосы..." © НТР)

Телеграм-бот

Дальше я взялся за самого телеграм-бота. Через openrouter подключил LLM для интерпретации гороскопов, в качестве модели выбрал Claude Haiku 4.5. Добавил базовые команды для генерации натальной карты, транзиты. Потом подумал и перешел на кнопки, так получилось понятнее для пользователя.

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

Заморочился даже на рефералки, они начисляют по 10 дополнительных кредитов пригласившему и тому, кто пришел. Было интересно сразу сделать "по-взрослому", хотя на текущем этапе развития это и избыточно.

Развернул я всё это добро на небольшой виртуалке, причем для каждого компонента развернул отдельно staging для тестирования, и отдельно прод с blue-green схемой, чтобы накатывать обновления без даунтайма для пользователей. Это тоже оверхед для пет-проекта, но мне было интересно с этим разобраться, так как в DevOps я не очень-то шарю.

Что получилось, и что дальше

В итоге, несмотря на большое количество усилий, у меня получился довольно минималистичный бот.

Поиграться с ним можно тут: @nocturna_astrology_bot

Ещё я сделал, чтобы этот же бот каждый день постил текущую интерпретацию транзита в отдельный телеграм-канал nocturna_astroday. Там пока всего 6 подписчиков, и все они боты, кроме меня самого.

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

Так что пишите в комменты, буду рад обратной связи. Тестируйте, ломайте, пишите баг-репорты. Можно репортить даже в самом боте (в разделе "Помощь" можно отправить мне ЛС через бота). Кому интересно поконтрибьютить - репы открыты.