Продолжаю рассказ. Про архитектуру и AI я уже поведал ранее, теперь — про место, где пользователь перестаёт быть «посетителем» и становится «хозяином своей вселенной». Про личный кабинет.

Зачем астрологу ваши паспортные данные

Начну с главного: астрология без даты рождения не работает вообще. Это как навигатор, которому не сказали адрес. Гороскоп, биоритмы, именины, лунные дни — всё это функции от трёх вещей: даты, времени и места рождения.

Поэтому личный кабинет у нас — не «довесок для галочки», как в интернет-магазинах, а ядро продукта. Без него сайт был бы витриной общих текстов. С ним — персональным сервисом.

И вот тут начинается интересная инженерная задача: как сделать так, чтобы пользователь заполнил анкету один раз, а дальше весь сайт знал, кто он?

Регистрация: скучные страницы с нескучными решениями

У нас классический email-first поток: /register → /verify-email → /set-password.

Казалось бы, почему не поставить сразу «Войти через Google» и не мучить людей? Решение осознанное: данные у нас чувствительные. Дата и время рождения — это почти биометрия в мире астрологии. Мы хотим, чтобы аккаунт был привязан к реальной почте, чтобы человек понимал: его анкета хранится у нас, а не у третьей стороны.

Технически аутентификация построена на Laravel Sanctum. Это токены вместо классических сессий: фронтенд (Next.js) и бэкенд (Laravel) — разные приложения, и им нужен честный API-контракт. При загрузке кабинета фронт спрашивает у бэка одну-единственную страницу правды:

GET /api/me
→ { user, subscription, calendar_subscriptions, profile }

Один запрос — и интерфейс знает: кто ты, какой у тебя тариф, на какие календари ты подписан. Дальше всё рендерится из этого состояния. Никаких «пять запросов на каждую плитку».

Профиль: три числа, которые меняют всё

В профиле пользователь заполняет:

• Дату рождения — определяет знак зодиака
• Время рождения — критично для точных расчётов (дома натальной карты считаются именно от времени)
• Место рождения — география влияет на астрономические расчёты
• Имя — и вот тут начинается перекличка фич

Заполнил один раз — и весь сайт перестраивается под тебя:

• Гороскопы сразу открываются на твоём знаке
• Биоритмы считают циклы от твоей даты
• Календарь именин знает имя
• Совместимость имён подставляет имя первым полем

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

«Мои гороскопы»: память вашей вселенной

Зачем хранить историю гороскопов? Потому что люди перечитывают их в неожиданные моменты. «А что мне писали в день собеседования?» «А в день знакомства?» Гороскоп эфемерен — сутки прошли и всё. Но сохранённая история превращает его в личный дневник.

Технический нюанс, которым горжусь: список /my-horoscopes генерируется статически (SSG), а вот карточка /my-horoscopes/[id] — динамическая (в выводе сборки она помечена значком ƒ). Почему? Потому что контент приватный. Его нельзя prerender’ить на билде — иначе Google проиндексирует чужие личные тексты. Динамический рендер с проверкой владельца — и приватность соблюдена.

/share/[uuid]: приватное, которым можно поделиться

Вот моя любимая фишка кабинета. Любой результат — гороскоп, расклад, анализ совместимости — можно опубликовать одной ссылкой.

Как устроено: при шеринге генерируется UUID v4. Это 128 бит чистой энтропии — ссылку невозможно угадать перебором.

Получается элегантный компромисс:

• профиль и история остаются приватными
• но конкретным результатом можно похвастаться подруге (или другу)

Публичная страница собирается без авторизации, с красивыми OG-тегами — то есть при вставке ссылки в Telegram или VK показывается карточка с заголовком и описанием, а не голая ссылка. Мелочь? Мелочь. Но именно такие мелочи делают шеринг массовым.

Календарные подписки: фича, которая возвращает людей

В дашборде живёт то, что я считаю главной retention-механикой проекта — подписки на персональные календари:

• именины
• лунные дни
• православные и мусульманские праздники
• дни посадки растений
• дни стрижки (да-да, это серьёзная категория для аудитории)

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

Почему это гениально для продукта? Потому что меняет модель поведения. Сайт перестаёт быть «зашёл раз в неделю за гороскопом» и становится «живу с этим каждый день». А для нас это означает возврат пользователей без единого рубля на рекламу.

Подписка и платежи: freemium без драм

Монетизация честная: базовые фичи бесплатны, глубина — по подписке. Страницы: /pricing (витрина тарифов), /subscription (управление), и пара недооценённых героев — /payment/success и /payment/fail.

Почему я называю их героями? Потому что 90% разработчиков делают их на отвяжись, а именно они определяют, останется ли человек клиентом.Payment-система после оплаты редиректит пользователя обратно к нам, и мы обязаны:

• на success — не просто сказать «оплачено», а показать, что именно открылось: «теперь тебе доступны месячные гороскопы и все календари»
• на fail — не обвинять пользователя, а спокойно объяснить шаг: «деньги не списались / карта отклонена, попробуйте ещё раз или другую карту»

Плюс параллельно работаем с вебхуками платёжной системы: редирект — для человека, вебхук — для правды в базе. Человек может закрыть браузер до редиректа, но подписка всё равно активируется корректно. Это та скучная надёжность, за которую потом не стыдно.

Техническая кухня кабинета, коротко

• Middleware-защита: все роуты кабинета закрыты; гость, попытавшийся зайти в /profile, мгновенно улетает на /login и возвращается обратно после входа
• Sanctum-токены хранятся в базе — сессию можно отозвать из интерфейса, как в серьёзных системах
• Redis-кэш профиля и подписок: кабинет открывается мгновенно, даже когда база под нагрузкой
• Приватность по умолчанию: данные рождения не попадают в логи, не отдаются публичными API и не участвуют в аналитике. Это не паранойя, это уважение.

UX-мелочи, которые решают всё

Финальный слой — то, что пользователь не назовёт, но почувствует:

• скелетоны вместо крутящихся спиннеров (глаз не устаёт)
• понятные тексты ошибок вместо «Error 500»
• мобильная вёрстка от и до (аудитория астрологии — на 80% телефоны)
• и та самая «тихая персонализация»: нигде нет кричащего «МЫ ЗНАЕМ О ТЕБЁ ВСЁ», просто всё уже подстроено.

Что просится дальше

Честный список хотелок:

1. Вход через Яндекс/Google — для тех, кому лень помнить пароль (вторым слоем, после email-базы)
2. Telegram-бот с утренним дайджестом по подписанным календарям — логичное продолжение календарных подписок
3. Семейные профили: добавить профили близких — и совместимость имён с гороскопами сойдутся внутри кабинета в одну большую фичу
4. Визуализация натальной карты — SVG-колесо с домами и аспектами, это уже высшая лига

Технически — это не сложные решения. Наработки по ним уже есть, и скоро всё будет реализовано.

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

В следующей главе буду рассказывать про платёжную кухню и тарифную модель подробнее, и немного про детективные истории продакшена (дублирующиеся роуты, падающие сборки, холодный старт контейнеров).

Подписывайтесь! Буду держать в курсе.

Личный кабинет можно самостоятельно пощупать здесь (регистрируйтесь) — РЕГИСТРАЦИЯ

Посмотрите весь сервис здесь: https://my.neiro-astro.ru/

Сообщение Личный кабинет в AI-астрологе: где магия становится личной. 2 часть появились сначала на Андрей Прокопенко.

Знаете, есть такие проекты, которые кажутся простыми снаружи, но внутри — целый оркестр технологий. «AI Астролог» — как раз такой. Давайте я расскажу, как он устроен.

О чём проект вообще?

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

Хочешь — толкование сна про летающего кота. Хочешь — анализ совместимости имён Александр и Анна (спойлер: там 2800 символов тёплого текста про любовь и дружбу).

За этой магией — серьёзная инженерия. И сейчас я покажу, как она работает.

Архитектура: три кита

Система стоит на трёх основных компонентах, как классический веб-стек, но с AI-слоем.

Frontend — это Next.js 14, современный React-фреймворк. Почему именно он? Потому что нам нужен был серверный рендеринг (SSR) для SEO. Когда Google-бот заходит на страницу /names/anna, он должен увидеть готовый HTML с заголовком и текстом, а не пустой <div id="root"></div>, который надо рендерить JavaScript’ом. Для контентного сайта это критично — без SSR нас бы просто не индексировали.

Backend — Laravel 11 на PHP 8.3. Да, PHP, и нет, это не архаизм. Laravel — это Rolls-Royce среди PHP-фреймворков. У него из коробки есть всё: очереди, кэш, миграции, админка Filament, аутентификация Sanctum. Когда тебе нужно быстро запустить продукт, а не изобретать велосипеды — Laravel экономит месяцы работы.

База данных — PostgreSQL 16. Надёжная, мощная, с отличной поддержкой JSON и полнотекстового поиска. Рядом живёт Redis 7 — он отвечает за кэш. Когда тысяча человек одновременно смотрят гороскоп Овна, мы не дёргаем базу каждый раз, а отдаём ответ из Redis за микросекунды.

Docker: контейнеры как Lego

Всё упаковано в Docker-контейнеры. Почему не просто «поставили на сервер»? Потому что это даёт нам воспроизводимость. Один разработчик пишет на Mac, другой на Linux, продакшен на Ubuntu — и везде всё работает одинаково. Плюс можно масштабировать: если нагрузка выросла, просто поднимаем ещё контейнеров.

Интересная деталь: backend работает в режиме network_mode: host. Это значит, что он напрямую слушает порт 8002 на хосте, без NAT’а. Решение нестандартное, но оно даёт нам минимальные задержки и упрощает сетевую конфигурацию.

AI-интеграция: самая интересная часть

Вот тут начинается магия. Мы используем целый букет неиросетей. В том числе и собственные наработки и глобальные модели. Если будет интересно — маякните. Расскажу подробнее. В двух словах тут не получится. По-сути, получается отдельная книга (страниц на 500)..

Промпт-инжиниринг: искусство разговора с AI

Самое сложное в AI — не подключить API, а научить модель писать правильно. Мы потратили недели на итерации промптов.

Плохой промпт:

Расскажи про имя Александр.

Результат: сухой текст со списками, эмодзи, заголовками — как из Википедии.

Хороший промпт:

Ты — эксперт по ономастике и истории имён. Пиши тёплый, 
живой текст на русском языке. Без списков, без эмодзи, 
без заголовков. Пиши связными абзацами. Расскажи про 
имя «Александр»: происхождение, значение, какие черты 
характера обычно приписывают носителям этого имени, 
известные люди с таким именем. Напиши 4-6 абзацев 
тёплого текста.

Результат: текст, который хочется читать. Живой, тёплый, с историей про Македонского и Пушкина.

Мы добавили параметр temperature: 0.75 — это делает текст разнообразнее. Если поставить 0.2, модель будет писать одно и то же. Если 1.5 — начнёт нести чушь. 0.75 — золотая середина.

Кэширование: не платим за одно и то же дважды

Каждый AI-запрос стоит денег. Поэтому мы агрессивно кэшируем. Когда пользователь проверяет совместимость «Александр + Анна», мы:

1. Генерируем хеш: md5("Александр|Анна")
2. Проверяем, есть ли результат в Redis
3. Если есть — отдаём за 1 мс
4. Если нет — запрашиваем у AI, сохраняем в кэш на 24 часа

Результат: 80% запросов обслуживаются из кэша, не нагружая AI API.

Frontend: скорость и SEO

Next.js даёт нам лучшее из двух миров:

• SSG (Static Site Generation) для страниц, которые редко меняются (например, /names со списком имён)
• SSR (Server-Side Rendering) для динамического контента (страница конкретного имени)
• ISR (Incremental Static Regeneration) — страницы обновляются в фоне каждые 60 секунд

Per-request генерация: умная ленивость

Вот элегантное решение, которым я горжусь. У нас 195+ имён в базе. Но что если пользователь вводит редкое имя, которого нет?

Вместо того чтобы говорить «не найдено», мы:

1. Проверяем, есть ли имя в БД
2. Если нет — генерируем on-the-fly через AI
3. Сохраняем в БД для будущих запросов
4. Отдаём пользователю

Так база растёт органически: чем больше людей пользуются, тем больше контента. Это называется lazy generation.

Защита от ошибок: production-ready код

Реальный пример из продакшена. Однажды API перестал возвращать поле related (похожие имена). Frontend упал с ошибкой Cannot destructure property 'by_origin' of undefined.

Решение — защитное программирование:

const related = data.related || {};
const by_origin = related.by_origin || [];
const by_letter = related.by_letter || [];

Теперь даже если API вернёт пустой объект, страница не упадёт. Это базовая гигиена, но удивительно, как часто её забывают.

Админка: модерация AI-контента

AI иногда пишет ерунду. Поэтому мы сделали админку на Filament 3 — это Laravel-пакет для быстрого создания админ-панелей.

Что умеет модератор:

• Просмотреть все 195+ имён
• Отфильтровать по происхождению (греческое, славянское…)
• Одобрить/отклонить контент массово
• Отредактировать текст вручную
• Увидеть, какие имена сгенерированы AI, а какие добавлены вручную

Интересная деталь: бейдж на странице имени показывает происхождение. Пользователь сразу видит, что «Анна» — еврейское, а «Ярослава» — славянское. Это добавляет доверия к контенту.

Перелинковка: SEO-магия

Поисковики любят, когда страницы связаны между собой. Мы сделали умную перелинковку:

На странице «Анна» показываем:

• 10 имён еврейского происхождения (Михаил, Мария, Иван…)
• 10 имён на букву «А» (Арина, Арсений, Алексей…)

Это не случайный список — это осмысленные связи, которые улучшают и UX, и SEO. Google видит, что страницы связаны тематически, и ранжирует их выше.

Совместимость имён: самая viral-фича

Эта функция стала хитом. Пользователи вводят два имени и получают 2800 символов анализа: как эти имена сочетаются в любви, дружбе, работе.

Технически:

• POST-запрос на /api/names/compatibility
• AI анализирует пару за 5-7 секунд
• Результат кэшируется на 24 часа
• На странице — кнопки «Поделиться» (Telegram, VK, WhatsApp, OK)

Почему viral? Потому что люди любят делиться результатами про себя и партнёра. Одна такая публикация в соцсетях = бесплатная реклама.

Масштаб в цифрах

• 195 имён с AI-толкованиями (100% coverage)
• 2,206 символов снов в базе
• 50+ API endpoints
• 30+ frontend страниц
• ~2-5 секунд на AI-генерацию
• 80% cache hit rate для совместимости

Что можно улучшить?

Честно говоря, есть куда расти:

Микросервисы. Сейчас AI-логика живёт внутри Laravel. При росте нагрузки логично вынести её в отдельный FastAPI-сервис (у нас уже есть Python-контейнер для астрологических расчётов).

CDN. Статические ассеты (картинки, CSS, JS) можно раздавать через Cloudflare или Yandex Cloud CDN. Это ускорит загрузку в разы.

WebSocket. Для real-time фич (например, live-чат с AI-астрологом) нужен WebSocket. Сейчас всё работает через HTTP-запросы.

Elasticsearch. PostgreSQL хорош, но для сложного поиска (например, «найди имена, которые означают ‘сильный’ и имеют славянское происхождение») Elasticsearch будет быстрее.

Kubernetes. Когда проект вырастет до миллионов пользователей, Docker Compose станет узким местом. K8s даст нам автомасштабирование и отказоустойчивость.

Главный вывод

Этот проект — пример того, как современный стек решает реальные бизнес-задачи. Мы не использовали технологии ради технологий. Каждый выбор был обоснован:

• Laravel — потому что быстро
• Next.js — потому что SEO
• PostgreSQL — потому что надёжно
• Qwen — потому что быстро и дёшево
• Docker — потому что воспроизводимо

Результат: продукт, который работает стабильно, масштабируется и приносит пользу пользователям. И да, нейросеть действительно пишет про любовь Александра и Анны лучше, чем некоторые человеческие астрологи.

P.S. Если вам интересно, как мы решали конкретные проблемы (дублирование роутов, холодный старт контейнеров, конфликты Next.js) — могу рассказать отдельно. Там были настоящие детективные истории.

Подписывайтесь! В следующей статье расскажу про личный кабинет. Это целый оркестр технологий и изящество решений в попытках их полноценного использования.

Вторую часть можно прочитать: ЗДЕСЬ

Сообщение Как мы построили AI-астролога: история изнутри появились сначала на Андрей Прокопенко.

Добавлена возможность выбора нескольких языков в активностях.

Добавлена первичная реализация API для подключения партнеров и сторонних приложений.

Сообщение Версия 1.1.2 появились сначала на Андрей Прокопенко.

В Пятигорске можно найти не только горы. Река Подкумок бежит в городской черте. Тем не менее, это горная река.

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

Подкумок, как горная река, отлично подходит для фотопрогулок. Летом, из-за частых дождей в горах (выше по течению) превращается в рычащую стихию. Если дождей нет — в спокойную, бирюзового цвета, речку. Множество порогов и перекатов делают каждый поворот реки уникальным.

Вот, немного фото с последней прогулки:

Видео с горной рекой Подкумок

Хотите со мной на фотопрогулку?

Выберите доступный вариант:

Все остальные варианты: ЗДЕСЬ

Сообщение Фотопрогулка по берегу горной реки в Пятигорске появились сначала на Андрей Прокопенко.

Друзья!

Я искренне рад тому, что мы с вами встречались на фотопрогулках.

Спасибо за предоставленный мне шанс стать проводником в мир фотографии!

Хочу поделиться с вами идеей получения интересных фото. Их можно посмотреть: ЗДЕСЬ

Также открываю доступ к архиву фото из моего телефона. Он будет постоянно пополняться.

Фотки можно посмотреть: ЗДЕСЬ

Кстати, их можно использовать. Участники фотопрогулок могут их использовать без ограничений.

Сообщение Для участников фотопрогулок появились сначала на Андрей Прокопенко.

Фотопрогулки по Пятигорску становятся все популярнее и популярнее. Это не банальные экскурсии с заученными гидами текстами. Это, буквально, погружение в атмосферу курорта.

В этой серии статей под названием «Пятигорск глазами туриста» буду показывать вам наиболее выигрышные «захваты» в объектив камеры вашего мобильного телефона.

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

Фотографии, естественно, увеличиваются при нажатии.

Что такое фотопрогулка по Пятигорску?

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

Во время прогулки вы сами получите практический опыт и знания о том, как сфотографировать так, чтобы не было стыдно. О прогулке по курортному городу можно узнать: ЗДЕСЬ

Сообщение Пятигорск глазами туриста. Фотографируем все красивые места в городе. Часть 1 появились сначала на Андрей Прокопенко.

UPD: Домен https://app.news-kmv.ru/ привязан

В настоящий момент приложение доступно по адресу: https://bbajphollslm0c6jrn5v.containers.yandexcloud.net/

После окончания подключения DNS приложение будет прописано по адресу: https://app.news-kmv.ru

Сообщение Рабочий адрес приложения появились сначала на Андрей Прокопенко.

На компьютер

На android

На Ios

Сообщение Как установить приложение? появились сначала на Андрей Прокопенко.

Нам очень не хотелось перегружать его информационно. Оставили только самое важное!

Приложение развивается. Будем признательны обратной связи.

Сейчас работают 3 глобальных раздела:

Оповещения о БПЛА и ЧС

Новости Ставропольского края

Афиша Ставропольского края

Вопросы:

Сообщение О приложении «КМВ Новости» появились сначала на Андрей Прокопенко.

На фото ночное движение облаков на вершине горы.

Сообщение Ночной Машук с туманом на вершине появились сначала на Андрей Прокопенко.