На моем VPS за 5 баксов наконец закончилось место, и MongoDB не может нормально работать (и отваливается первой). Хотелось научиться переносить бд с одного сервера на другой без остановки (хотя сейчас это не так критично, потому что все приложения уже упали ха-ха, даже через Compass не могу подключиться). В этой статье я покажу, как перенести MongoDB с одного сервера на другой с помощью репликации.

🔧 Зачем использовать репликацию

Репликация MongoDB позволяет создать несколько серверов, где:

• PRIMARY принимает все записи,
• SECONDARY синхронизирует данные и может использоваться для чтения или бэкапа.

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

⚙️ Подготовка серверов

На старом сервере:

• Уже установлена и запущена MongoDB (у меня древняя версия 4.2). Проверить версию можно так mongod --version
• Есть пользователь admin с правами root (если нет, то создадим так, подключившить к mongo shell на сервере):

use admin
db.createUser({
  user: "admin",
  pwd: "StrongPass123",
  roles: ["root"]
})

На новом сервере:

Установлен Docker, т. к планируется запуск Mongo в контейнере.

🚀 1. Создаём реплика-сет на старом сервере

Открываем Mongo shell:

mongo -u admin -p StrongPass123 --authenticationDatabase admin

Инициализируем реплика-сет:

rs.initiate({
  _id: "rs0",
  members: [
    { _id: 0, host: "old.ip.address:27017" } // IP старого сервера
  ]
})

Проверяем:

rs.status()

Должен появиться статус PRIMARY.

🔐 2. Настраиваем ключ безопасности

MongoDB требует keyFile для репликации между узлами с включённой авторизацией. Это позволяет вам ограничить круг ip, который может подключиться к вашей базе для репликации. Есть вариант вообще отключить авторизацию, но тогда есть вероятность что вашу бд могут дропнуть какие нибудь боты.

Создаём ключ на старом сервере:

openssl rand -base64 756 > mongodb-keyfile
sudo mv mongodb-keyfile /etc/mongodb-keyfile
sudo chmod 400 /etc/mongodb-keyfile
sudo chown mongodb:mongodb /etc/mongodb-keyfile

Для этого ключа важно выставить права (400) и владельца mongodb (что и сделано выше).

В /etc/mongod.conf добавляем:

replication:
  replSetName: rs0
security:
  keyFile: /etc/mongodb-keyfile
  authorization: enabled

replSetName - имя реплики
keyFile - путь к ключу.

Перезапускаем MongoDB:

sudo systemctl restart mongod

Если при старте будет ошибка bad file или yaml-cpp: unknown escape character, значит, файл содержит переносы строк или кавычки — нужно убедиться, что ключ в одну строку и без пробелов в начале. Иногда mongo может пытаться прочесть ваш файл как yml, мне помогло прописать путь до файла в кавычках.

🐳 3. Запускаем MongoDB на новом сервере в Docker

На новом сервере создаём mongodb-keyfile с тем же содержимым:

echo "тот_же_ключ" > mongodb-keyfile
chmod 400 mongodb-keyfile

Создаём docker-compose.yml:

version: "3.8"

services:
  mongo:
    image: mongo:4.2
    container_name: mongo
    restart: unless-stopped
    volumes:
      - ./data:/data/db
      - ./mongodb-keyfile:/etc/mongodb-keyfile
    command: >
      mongod
      --replSet rs0
      --keyFile /etc/mongodb-keyfile
      --bind_ip_all
    ports:
      - "27017:27017"

Запускаем:

docker compose up -d

🔗 4. Добавляем новый сервер как реплику

Подключаемся к PRIMARY (на старом сервере) и добавляем ноду:

mongo -u admin -p StrongPass123 --authenticationDatabase admin

rs.add({ host: "new.ip.address:27017" })

Проверяем:

rs.status()

Сначала в ответе статуса для новой ноды будет содержаться параметр state STARTUP2. Через некоторое время новая нода станет SECONDARY — это значит, что синхронизация завершена.

🕵️ 5. Проверяем синхронизацию

Когда статус SECONDARY без ошибок, данные уже полностью скопированы.

Можно убедиться:

rs.printSecondaryReplicationInfo()

Если всё ок — база на новом сервере полностью актуальна.

🔁 6. Переключаем PRIMARY

Теперь можно безопасно «переехать»:

Останавливаем запись на старый сервер (или поднимаем приложение с переменной MONGODB_URI указывающей на новый IP).

Подключаемся к старому серверу:

rs.stepDown()

Теперь новая нода станет PRIMARY.

Можно передать параметр времени в секундах на сколько ваша старая нода перестанет быть PRIMARY (если вы просто экспериментируете с нодами)

rs.stepDown(60)

🧱 7. Удаляем старый сервер из реплики

После проверки что все данные скопированны, на новом сервере заходим в mongo shell в докере:

docker exec -it containerName mongo -u admin -p StrongPass123 --authenticationDatabase admin

И удаляем старую ноду

rs.remove("old.ip.address:27017")

⚠️ Важно

Т к теперь БД сконфигурирована как replice-set, подключаться к ней нужно с дополнительным параметром (replicaSet=rs0):

admin:StrongPasss123@ip.address:27017/db_name?authSource=admin&authMechanism=DEFAULT&replicaSet=rs0

⚠️ Подводные камни

Вот на чём можно споткнуться (и на чём мы действительно споткнулись 😅):

Ошибки с keyFile

Файл должен быть одинаков на всех серверах.
Права только 400.
Без кавычек, без переносов строк.

Неправильный host
При инициализации реплика-сета Mongo может автоматически подставить внутреннее имя ubuntu-s-1vcpu....
Нужно вручную заменить:

cfg = rs.conf()
cfg.members[0].host = "old.ip.address:27017"
rs.reconfig(cfg, { force: true })

Ошибка Unauthorized при rs.initiate()
Значит ты выполнил команду, когда уже включена авторизация, но не залогинился как admin (не передал --authenticationDatabase admin).

Firewall и порты
Обязательно надо открыть порт 27017 между серверами.

💡 Бонус: Можно добавить третью ноду-«арбитер», которая не хранит данные, но поддерживает отказоустойчивость:

rs.addArb("192.168.1.100:27017")

На этом все. Подписывайтесь на мой Telegram-канал про разрабтку и не только!
Всем добра! :)

Сервера, как правило, хостят множество сайтов, но запрос по url всегда приходит на порт 80. Сделаем стандартную настройку Nginx для обработки HTTP-трафика с порта 80 и HTTPS с порта 443 с использованием бесплатных сертификатов Let's Encrypt. Эта конфигурация включает перенаправление с HTTP на HTTPS, интеграцию Certbot для выпуска сертификатов и автоматизацию их обновления, что критично для современных веб-приложений.​​

Базовая настройка портов в Nginx

После установки новой системы и nginx, в папке /etc/nginx/sites-available/ есть стандартная конфигурация в файле default. Создадим рядом другой конфиг с лубым именем (например you-site.ru.conf). В этом файле конфигурации создадим два блока server: один для порта 80, другой для 443. Для порта 80 настроим простое перенаправление на HTTPS, чтобы все незащищённые запросы автоматически переходили на безопасный вариант.​

Пример конфигурации для порта 80 (HTTP)

server {     
    listen 80;
    listen [::]:80;     
    server_name example.com www.example.com; 
}

Эта директива return 301 генерирует постоянный редирект, сохраняя путь запроса и серверное имя. Укажите ваш домен в server_name для точной обработки.

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

Выпуск SSL-сертификатов с Certbot

Certbot — инструмент от EFF, который автоматизирует получение сертификатов Let's Encrypt через ACME-протокол. Он верифицирует домен по HTTP (порт 80) и интегрируется с Nginx, автоматически добавляя ssl-директивы в конфигурацию.​

Установка и запуск Certbot

На Ubuntu/Debian выполним:

sudo apt update && sudo apt install certbot python3-certbot-nginx

Затем получим сертификат:

sudo certbot --nginx -d example.com -d www.example.com

Certbot запросит email для уведомлений, согласится с условиями и предложит редирект (выберите опцию 2 для автоматического перенаправления). Он создаст файлы в /etc/letsencrypt/live/example.com/ и обновит ваш .conf-файл. Если нужно, добавьте блок location для .well-known/acme-challenge в HTTP-блок для верификации:​

location /.well-known/acme-challenge {
    root /var/www/letsencrypt;
    allow all; 
}

Создайте директорию letsencrypt eсли ее нет: sudo mkdir -p /var/www/letsencrypt.​

После того как сертификаты выпущены, можно добавить редирект с 80 порта на 443 (с http на https)

server {     
    listen 80;
    listen [::]:80;     
    server_name example.com www.example.com;
  
    # redirect
    return 301 https://$server_name$request_uri;
}

Настройка порта 443 (HTTPS)

Для HTTPS добавим ssl-параметры в блок server. Их скорее всего создаст сам certbot (но если нет, добавим сами). Укажем пути к сертификату и ключу, а также рекомендуемые протоколы и шифры для безопасности.​

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name example.com www.example.com;

    # Пути к сертификатам (будут заполнены Certbot)
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # Рекомендуемые SSL-настройки
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;
    ssl_session_cache shared:SSL:1m;
    ssl_session_timeout 5m;

    location / {
        # Пример: прокси на backend (например, порт 8080)
        proxy_pass http://127.0.0.1:8080/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Здесь http2 улучшает производительность, а proxy_pass полезен, если сайт работает на другом порту (например на 8080). После изменений проверьте синтаксис командой sudo nginx -t и перезагрузите: sudo systemctl reload nginx.​

Автоматическое обновление сертификатов

Сертификаты истекают через 90 дней, но Certbot настраивает автообновление по умолчанию через systemd-timer. Таймер проверяет сертификаты дважды в день и обновляет, если осталось менее 30 дней.​

Проверка и настройка обновления

Проверьте статус: sudo systemctl status certbot.timer. Для теста: sudo certbot renew --dry-run. Если таймер не активен, включите: sudo systemctl enable certbot.timer && sudo systemctl start certbot.timer. Certbot использует post-hook для reload Nginx: --post-hook "systemctl reload nginx", что минимизирует downtime. Альтернативно, добавьте в crontab (sudo crontab -e):​

0 */12 * * * /usr/bin/certbot renew --quiet --nginx

Это запустит проверку каждые 12 часов.​

Тестирование и советы

После настройки протестируйте сайт: https://example.com должен показывать зелёный замок без предупреждений. Используйте инструменты вроде SSL Labs для проверки (ssllabs.com/ssltest). Если проксируете на другой порт (как 8080), убедитесь, что backend поддерживает X-Forwarded-Proto для корректной работы HTTPS. Для нескольких доменов повторяйте процесс с --nginx -d domain2.com. Избегайте слабых шифров и регулярно обновляйте Nginx для патчей безопасности.​

Эта конфигурация сделает любой сайт полностью защищённым и готовым к продакшену.

Я освежал эти знания, пока готовил к продакшену свой блог с короткими статьями по разработке https://tldread.ru.

Сложно придумать хороший промпт если не знаешь всех понятий для съемки и ее настройки. Я попросил chatgpt мне собрать список словосочетаний, которые стоит использовать при составлении промпта.

🎥 1. Типы кадров (Camera Shots)

🚶 2. Движение камеры (Camera Movement)

💡 3. Освещение (Lighting)

🌈 4. Атмосфера и цвет (Mood / Color Tone)

🧱 5. Композиция и перспектива

🧍 6. Типы сцен и действий

Вот пример промпта:

“A product showcase of a modern smartwatch on a clean white background, smooth orbiting camera, soft studio lighting, shallow depth of field, cinematic color grading, minimal text overlay, 8 seconds video.”
(Демонстрация современного смарт-часа на белом фоне, плавное вращение камеры, мягкий студийный свет, малая глубина резкости, кинематографическая цветокоррекция, минимальный текст, 8 секунд.)

Привет! 20 и 21 октября в Москве, в Кластере "Ломоносов" пройдет одна из топовых конференций для фронтов – Frontend Conf 2025 🚀. В этом году я сам решил поехать и послушать и вот мои 10 причин посетить Frontend Conf 2025. Поехали! (Кстати, в конце статьи промокод на 5% 😊)

1. Погружение в реальные тренды

Организаторы конференции собрали повестку на основе опроса более 300 экспертов. Темы — не абстрактные догадки, а отражение реальных потребностей индустрии. Вместо устаревших и заезженных решений, которые кочуют из одной конфы в другую, можно послушать про внедрение AI, PWA, микрофронтов и архитектурных паттернов. Все доклады основаны на боли реальных компаний, где спикеры рассказывают про свой опыт, подводные камни и компромиссы на которые они пошли при внедрении того или иного решения. Плюсом, получаете срез технологий на текущий момент, при помощи которого можно проследить тренд и составить свою дорожную карту развития в плане технологий.

2. Практика вместо теории

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

3. Архитектура как движущая сила роста

В фокусе — переход от монолитов к модульным системам и микрофронтам (да, это тренд последних 5 лет, тут ничего нового). На докладах можно посмотреть, как выстроить гибкую и поддерживаемую архитектуру. Обсуждаются DDD, Module Federation, современные подходы к интеграции и как прививать культуру хороших практик и паттернов в команде, ведь архитектура — это не только код. Плюсом участники смогут понять, как масштабировать проекты без хаоса и как вообще сделать возможным масштабирование на начальных этапах проекта.

4. Искусственный интеллект в работе фронтенда

ИИ перестаёт быть “игрушкой” и становится частью рабочего процесса. Многие разработчики пользуются им только как помощником при разработке и только в ограниченных кейсах, а его возможности намного шире. На конференции покажут, как использовать LLM и AI-сервисы в пайплайне фронтенда. ИИ секция также включает в себя темы по безопасности, рискам и защите от уязвимостей. Также ожидается много практики — от генерации кода до анализа UX: вы поймёте, как внедрить AI так, чтобы он приносил пользу, а не проблемы.

5. PWA и мобильный опыт

Особое внимание уделено прогрессивным веб-приложениям. Многие компании из за санкций начали быстро переводить свои мобильные продукты в веб и тут за пару лет накопилось много опыта и интересных решение, которые стоит послушать. Вы узнаете, как оптимизировать кэширование, offline-режимы и lazy-loading, будут кейсы внедрения PWA в банках и крупных продуктах. Это хороший шанс понять, как создавать веб-приложения с UX уровня нативных, а также как ускорить релизы и обойти ограничения App Store.

6. Культура, процессы и рост разработчиков

Frontend Conf — не только про код, но и про людей. В программе есть треки про карьеру, софт-скиллы и лидерство, разбираются кейсы роста от мидла до архитектора, обсуждается, как выстраивать гильдии и развивать культуру команд.
Это отличная возможность прокачать навыки, которые нужны для технического и карьерного роста.

7. Возможность задать экспертам вопросы

Оооо, это моя любимая часть. Доклады — только начало: после выступлений можно пообщаться напрямую или же взять микрофон на секции Q&A. У меня как у человека, который часто хочет сделать идеально, но не знает как, всегда в кармане десяток вопросов и это лучшее место, где можно их задать.
Вы сможете уточнить детали, задать вопросы по своему кейсу, ведь живой диалог часто даёт больше ценности, чем сама презентация. Сами спикеры охотно делятся опытом, который не попадает в слайды. Это реальный способ решить свои рабочие проблемы за минуты.

8. Доступ к инструментам и спонсорам

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

9. Возможность проявить себя и понетворкать

Frontend Conf — площадка, где можно выступить или заявить о себе.
Даже как слушатель вы становитесь частью сообщества – в перерыве между докладами можно обкашлять вопросики, обсудить доклады и спикеров с коллегами. Плюс нетворкинг поможет тем, кто топит за личный бренд или ищет новые предложения и интересные проекты.

10. Инвестиция в себя

Поездка на конференцию — это вложение, которое окупается. Даже 1–2 идеи, внедрённые в проект, оправдывают участие (да и твой менеджер видит, что ты не просто пиво попить скатался на конфу).
Вы получаете знания, которые сложно собрать самостоятельно, потому что в интернете полно разных практик и подходов и не все они правильные (почитайте тот же medium). К тому же окружение единомышленников мотивирует на новые свершения, может пет-проект стартанете с AI, может блог заведете. Frontend Conf — это заряд энергии и план действий на год вперёд.

Frontend Conf 2025 — это место, где встречаются тренды, практика и профессионалы. Если вы хотите расти, внедрять новое и быть в числе первых — не пропустите конфу! 🚀

А по промокоду fc25_front_end_dev действует скидка 5%

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

Как мониторить состоянии сети в регионе

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

Что дальше?

Первая идея была запустить как-нибудь Telegram бота прямо на нем, но единственная проблема – как отправить сообщение при отказе мобильной сети. Т.к. я пишу на NodeJS, то у меня нет возможности на этой платформе переключить сеть на wifi (ну или я о ней не знаю, но все равно это решение нестабильное). С другими платформами (нативной разработки под андроид, например) заморачиваться не хочу даже с чатом гопоты.

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

Как превратить смартфон в платформу для исполнения кода?

Есть замечательное приложение для Androind – Termux, и его различные модификации. По факту Termux – это приложение-эмулятор терминала Linux для Android, которое предоставляет полноценную Linux-среду на смартфоне или планшете без необходимости root-прав. Оно позволяет устанавливать и запускать множество программ из репозитория Linux с помощью пакетного менеджера pkg, используя командную строку. Можно даже поставить nodejs и запускать сервер на смартфоне. Нам же достаточно sh скрипта, который при помощи curl будет в бесконечном цикле отправлять запросы на наш сервер.

Заходим в termux и устанавливаем curl

pkg install curl cronie -y

создаем наш скрипт (с помощью редактора nano): nano heartbeat.sh

#!/data/data/com.termux/files/usr/bin/bash

while true
	do
		curl -H "Authorization: Bearer your_auth_secret" http://YOUR_VPS_DOMAIN/heartbeat
    sleep 60
done

Добавим заголовок аутентификации, чтобы абы кто не мог слать запросы на наш сервер Authorization: Bearer your_auth_secret

Сделаем его исполняемым: chmode +x heartbeat.sh

Перед запуском скрипта выполним команду termux-wake-lock (это поможет не гасить вашу сессию termux при выключении экрана).

Стартуем ./heartbeat.sh

Можно погасить экран. Смартфон, конечно, будет оптимизировать работу программ, чтобы сэкономить батарею, и запросы будут отправляться реже, но для нас это не критично (да и termux-wake-lock должен помочь) .

Делаем бота

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

Стартует сервер, который будет принимать запрос от нашего смартфона. Сохраняем время последнего пришедшего запроса для статистики. Если в течение 5 минут нет запросов, значит, пропал мобильный интернет.
Пользователь бота при старте может настроить время ежедневного уведомления, чтобы проснувшись, знать статус сети. В назначенное время ему придет сообщение со статусом. Либо можно руками проверить статус, вызвав команду /status.
Пользователь бота также может подписаться на смену статуса командой /setstatuschange. Но это, наверно, больше для дебага, либо для особо любознательных пользователей домашнего интернета.

Добавил немного админских утилит, например рассылки сообщений по юзерам, чтобы например уведомлять о нововведениях или работах/сбоях.

Ссылка на репозиторий GitHub

Деплой

Такие небольшие приложения я привык разворачивать при помощи pm2, а деплоить – обычным sh скриптом при помощи rsync и ssh команд. Кстати, наконец разобрался почему у меня иногда не проходит стадия установки зависимостей. Оказалось что при запуске ssh команд нужно подгружать nvm.sh профайл чтобы ваша ssh сессия знала про nvm и текущую версию node.

На этом всё. Спасибо за внимание!
Подписывайтесь на мой Telegram канал Sleepless Tech.

Eleventy (или 11ty) — это легковесный генератор статических сайтов, идеально подходящий для проектов, где нужно быстро и гибко собрать сайт на чистом HTML, CSS и JavaScript. В моём информационном пузыре он давно не на слуху, потому что давно хайпуют NextJs и RemixJs. Но для того чтобы делать лендинги или простые статические страницы вам не нужен React или другие фреймворки. Если вам нужно наклепать пачку однотипных (или не очень) лендингов, главное, что вам нужно - это шаблонизатор. Основная фишка 11ty это как раз шаблоны, которые удобно наполнять, например, через Markdown файлы.

Здесь сохраню основные фишки, которые немного упростят разработку на Eleventy.

1. Использование шаблонов Nunjucks (njk) и Markdown

Одно из главных преимуществ Eleventy — поддержка шаблонов и Markdown «из коробки». Вы можете легко разделить структуру HTML и данные. Я использую Nunjucks для шаблонов и Markdown для хранения данных, которые будут наполнять шаблон:

src/urlpath/project.md

--- 
title: Мой проект 
layout: layout.njk 
--- 

header: Hello

## Описание проекта 
Этот сайт создан с помощью Eleventy.

src/_includes/layout.njk

<!DOCTYPE html> 
<html lang="ru"> 
	<head> 
		<meta charset="UTF-8" /> 
		<title>{{ title }}</title> 
	</head> 
	<body> 
		<h1>{{header}}</h1>
		<main> {{ content | safe }} </main> 
	</body> 
</html>

Такой подход позволяет быстро наполнять сайт контентом, не повторяя разметку вручную (фильтр safe означает, что вы вставляете здесь не просто строку, а html код и его не нужно подвергать санитизации - очистке от вредоносного кода)

2. Поддержка --pathprefix для настройки префикса статики

Если вы размещаете сайт в подкаталоге (например, https://pdf-convert.ru/welcome), Eleventy позволяет указать префикс для всех относительных ссылок. Установите плагин HTMLBasePlugin и добавьте его в свой конфиг:

eleventy.config.js

const { HtmlBasePlugin } = await import("@11ty/eleventy");

// остальной конфиг для 11ty (пример моего полного конфига будет далее)
eleventyConfig.addPlugin(HtmlBasePlugin);

И запускайте сборку с помощью скрипта eleventy --pathprefix nextlevelpath, где nextlevelpath относительный путь.

Теперь вы можете прописывать пути к статике в вашем шаблоне так:

<link rel="stylesheet" href="/styles/base.css" />

А Eleventy автоматически добавит нужный префикс (/nextlevelpath/styles/base.css).

3. Минификация скриптов с помощью esbuild

Выпускать ваш сайт в продакшн не сжав js - нехорошо. 11ty не имеет встроенного минификатора, поэтому мы прикрутим его сами. Для этого после сборки проекта можно минифицировать JS-файлы при помощи esbuild (здесь полный конфиг для моей сборки):

eleventy.config.js

const esbuild = require("esbuild");
const fs = require("fs");
const path = require("path");

module.exports = async function (eleventyConfig) {
  const { HtmlBasePlugin } = await import("@11ty/eleventy");
  eleventyConfig.addPlugin(HtmlBasePlugin);
  // копируем статику при билде (скрипты, стили, картинки и тп)
  eleventyConfig.addPassthroughCopy("src/styles");
  eleventyConfig.addPassthroughCopy("src/fonts");
  eleventyConfig.addPassthroughCopy("src/img");
  eleventyConfig.addPassthroughCopy("src/scripts");
  eleventyConfig.addPassthroughCopy("src/video");

  // минифицируем скрипты
  eleventyConfig.on("afterBuild", () => {
    const scriptDir = "src/scripts";
    const files = fs
      .readdirSync(scriptDir)
      .filter((file) => file.endsWith(".js"))
      .map((file) => path.join(scriptDir, file));

    return esbuild.build({
      entryPoints: files,
      outdir: "_site/scripts",
      minify: process.env.ELEVENTY_ENV === "production",
      sourcemap: process.env.ELEVENTY_ENV !== "production",
    });
  });

  eleventyConfig.addWatchTarget("src/scripts/");
   
  // сборка будет сохраняться в папку _site
  return {
    dir: {
      input: "src",
      output: "_site",
    },
  };
};

Теперь ваши скрипты будут автоматически минифицированы при продакшен-сборке.

4. Создание и использование глобальных переменных

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

eleventy.config.js

const isProd = process.env.ELEVENTY_ENV === "production"; 

module.exports = { 
    baseUrl: isProd ? "https://pdf-convert.ru/welcome" : "", 
}

Использование в шаблоне:

<meta property="og:image" content="{{ site.baseUrl }}{{ metaImage }}" />

Это удобно для ссылок, изображений, CDN и мета-данных.

5. Автоматическое добавление глобальных данных через addGlobalData

По факту это немного другой способ сделать то же самое, что и в предыдущем пункте. Чтобы не создавать вручную 11tydata.js, можно задать переменные в конфиге:

const isProd = process.env.ELEVENTY_ENV === "production";

module.exports = function(eleventyConfig) {
    eleventyConfig.addGlobalData("isProd", isProd); 
	return { 
			dir: { input: "src", output: "_site", }, 
			pathPrefix: isProd ? "/welcome" : "/", 
    	}; 
};

Теперь isProd доступна в любом шаблоне:

{% if isProd %} <script>/* production analytics */</script> {% endif %}

6. Использование переменных в css файлах

Например, для указания импорта шрифтов мне нужно было указать префикс. К сожалению pathPrefix не работает для css, а только для шаблонов. Для того чтобы можно было использовать переменные, можно превратить css файлы в шаблонный, поменяв расширение на css.njk.  Обязательно в шаблонном файле нужно прописать имя которое должно быть присвоено файлу после генерации css из этого темплейта и параметр отвечающий за то, чтобы из этого темплейта не создавался html файл.

base.css.njk

---
permalink: /styles/base.css
eleventyExcludeFromCollections: true
---
# Теперь можно использовать переменные в шаблоне

@font-face {  
	font-family: "Manrope";  
    font-style: normal;  
    font-weight: 400;  
    src: url("{{ site.baseUrl }}/fonts/Manrope-Regular.ttf") format("truetype");
 }

Можно глянуть примеры лендигов сделанных по одному шаблону:

PDF to PNG Chrome extension
Combine PDF Chrome extension
Compress PDF  Chrome extension

Теперь после билда можно закинуть вашу сгенерированную статику на сервер, чтобы ее раздавал nginx и все готово!

В общем, Eleventy — мощный и простой инструмент для сборки статических сайтов. Он идеально подойдёт как для лендингов, так и для документированных сайтов, блогов и расширений — особенно если вы хотите сохранить контроль над HTML, CSS и JS, не используя тяжёлые фреймворки.

Подписывайтесь на мой канал SleeplessTech

При создании расширения для Chrome довольно удобно аутентифицировать пользователя по логину в Chrome. Потому что если он совершил вход в свой аккаунт, то можно не требовать дополнительно логиниться в ваше приложение. Для этого Chrome предоставляет разработчикам расширений identity функционал.

Чтобы им воспользоваться нужно опубликовать черновик вашего расширения в Chrome Web Store для того, чтобы у вашего расширения появился id (вида: idhnkoehnkpmejapcxxxxlpfldsf, можно найти на странице расширения).

Затем нужно перейти в Google Cloud Console создать проект (либо выбрать существующий). На главной странице вашего проекта перейти в Api & Services.

Слева вкладка Credentials, нам туда.

Создаем новый креды: Create Credentials → OAuth 2.0 Client ID

Application type: Chrome extension
Item ID: id вашего расширения вида idhnkoehnkpmejapcxxxxlpfldsf
Также можно подтвердить что это ваше расширение.
Нажимаем создать.

В итоге после редиректа в таблице в графе ClientId будет ваш id, который нужно будет вставить в манифест (он вообще публичный, но в git его лучше не комитать).

Теперь для локальной разработки важно, чтобы id вашего приложения оставался постоянный (т к когда вы загружаете распакованное расширение при локальном дебаге, он меняется)
Для этого в Chrome Web Store во вкладке Пакет на странице с вашим расширением ищем графу Открытый ключ, кликаем, копируем.

Вставляем наши данные в манифест:
Открытый ключ
"key": "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKJHFDISJHFKJHDKJHSKJFHSJ"
Разрешения:
"permissions": ["identity", остальные ваши расзрешения]
ClientId из Cloud Console:

"oauth2": {
	"client_id": "YOUR_CLIENT_ID.apps.googleusercontent.com",
    "scopes": ["https://www.googleapis.com/auth/userinfo.email"]
 }

Готово!

Теперь можно запрашивать токен пользователя в content.js, при отправке запроса например:

function getAuthToken(res: (res: string) => void, rej: () => void) {
  chrome.identity.getAuthToken({ interactive: false }, (token) => {
  /// если возможно, запрашиваем без окна oauth2
    if (chrome.runtime.lastError || !token) {
      console.warn("Silent auth failed:", chrome.runtime.lastError?.message);
 
/// если не вышло, запрашиваем с попапом oauth2
      chrome.identity.getAuthToken(
        { interactive: true },
        (interactiveToken) => {
          if (chrome.runtime.lastError || !interactiveToken) {
            console.error(
              "Interactive auth failed:",
              chrome.runtime.lastError?.message
            );
            rej();
            return;
          }
/// вот наш токен
          res(interactiveToken);
        }
      );

      return;
    }
/// вот наш токен
    res(token);
  });
}

На сервере проверяем, что токен валидный через GET запрос на https://www.googleapis.com/oauth2/v3/tokeninfo?access_token=${token}

В ответе получим

{
    azp: '81800004758-xxxxxxxxx.apps.googleusercontent.com',
    /// проверим что aud совпадает с вашем clientid из cloud console
    aud: '818600004758-xxxxxx.apps.googleusercontent.com',
    sub: '101158204829854056900',
    scope: 'https://www.googleapis.com/auth/userinfo.email openid',
    exp: '1745297288',
    expires_in: '3598',
    email: 'test@gmail.com',
    email_verified: 'true',
    access_type: 'online'
}

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

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

Пара шагов для того, что ваше приложение или нужная утилита запускалась после старта системы. Для примера возьмем утилиту базы данных pocketbase.

Создадим юнит-конфиг для сервиса
sudo nano /etc/systemd/system/pocketbase.service

[Unit]
Description=PocketBase service
After=network.target

[Service]
ExecStart=/path/to/pocketbase serve --http=8090 # команда запуска включающая полный путь к запускаемому файлу и параметры (параметры можно передать через Environment)
WorkingDirectory=/path/to/ #путь до директории где лежит запускаемый файл
Restart=always
User=your-username # ваш юзер
Environment=PORT=8090 # можно прокинуть переменные окружения в таком формате

[Install]
WantedBy=multi-user.target

Теперь выполним:

sudo systemctl daemon-reexec — перезапускает сам процесс systemd

sudo systemctl daemon-reload — пересчитывает (перезагружает) конфигурационные файлы systemd (например, .service файлы). Нужно выполнять после изменений в юнит-файлах.

sudo systemctl enable pocketbase — добавляет юнит pocketbase.service в автозагрузку, чтобы он запускался при старте системы.

sudo systemctl start pocketbase — немедленно запускает сервис pocketbase

Если вам нужно изменить юнит файл после создания, то можно выполнить только эти 2 команды:

sudo systemctl daemon-reload

sudo systemctl restart pocketbase

Ну вот и все, ваш сервис готов!

Подписывайтесь на мой телеграм-канал про разработку

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

🔁 Итераторы и их вспомогательные методы

Если ты когда-либо делал цепочку преобразований массива вроде:

arr.slice(10, 20).filter(el => el < 10).map(el => el + 5);

…то ты, возможно, не задумывался, насколько это неэффективно. Каждое преобразование создаёт новый массив. Для больших массивов (>500K элементов) это может стать серьёзной проблемой.

С недавних пор в JavaScript появились итераторные помощники — методы, которые работают как map, filter и т.д., но не создают временные массивы, а возвращают новые итераторы.

Вот основные:

drop(n) — пропускает n элементов (аналог slice(n)).

take(n) — берёт максимум n элементов с начала (аналог slice(0, n)).

some(fn) / every(fn) — аналоги одноимённых методов массива.

filter(fn) / find(fn) / map(fn) / flatMap(fn) — всё как в массивах.

reduce(fn, initial) — как reduce массива, но для итераторов.

forEach(fn) — вызывает функцию для каждого элемента.

toArray() — преобразует итератор в массив.

Их можно использовать с помощью Iterator.from() или, например, arr.values():

arr.values()
  .drop(10)
  .take(10)
  .filter(el => el < 10)
  .map(el => el + 5)
  .toArray();

⚠️ Поддержка появилась недавно. Например, Safari начал поддерживать только с 31 марта 2025 года, так что пока лучше использовать с осторожностью.

📍 Метод at()

Метод Array.prototype.at() — это удобный способ получить элемент по индексу. Самое классное — он поддерживает отрицательные индексы:

[10, 20, 30].at(-1); // 30
[10, 20, 30].at(-2); // 20

Прощай, arr[arr.length - 1].

🧩 Promise.withResolvers()

Раньше, чтобы получить resolve и reject вне Promise, писали так:

let resolve, reject;
const promise = new Promise((res, rej) => {
  resolve = res;
  reject = rej;
});

Теперь можно проще:

const { promise, resolve, reject } = Promise.withResolvers();

📝 Замена строк с колбэком

Методы replace и replaceAll могут принимать функцию, а не строку:

let counter = 0;
console.log("NUMBER, NUMBER, NUMBER".replaceAll("NUMBER", (match) => `${match}=${++counter}`));
// → NUMBER=1, NUMBER=2, NUMBER=3

Позволяет эффективно делать множественные замены за один проход.

🔄 Обмен значениями

Не надо больше писать:

const temp = a;
a = b;
b = temp;

Теперь можно элегантнее:

[a, b] = [b, a];

Красиво и просто.

📦 structuredClone()

Альтернатива JSON.parse(JSON.stringify(obj)), но безопаснее и быстрее. Она:

• Поддерживает NaN, undefined, bigint, циклические ссылки.
• Работает быстрее и не ломается на рекурсивных объектах.

const obj = {};
obj.self = obj;

const clone = structuredClone(obj);
console.log(clone.self === clone); // true

🔖 Tagged templates

Многие знают про шаблонные строки, но не про тегированные шаблоны, которые позволяют обрабатывать строки функцией.

Пример — экранирование HTML:

function escapeHtml(strings, ...values) {
  const div = document.createElement("div");
  return strings.reduce((acc, str, i) => {
    div.textContent = values[i] ?? "";
    return acc + str + div.innerHTML;
  }, "");
}

console.log(escapeHtml`<br> ${'<script>'}`); // <br> &lt;script&gt;

Позволяет кастомизировать шаблонные строки.

🧠 WeakMap / WeakSet

Как Map и Set, но:

• ключи только объекты (не строки/числа)
• элементы могут быть автоматически удалены при потере ссылок (garbage collection)

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

const map = new WeakMap();
{
    const obj = {};
    map.set(obj, "value");
} // obj больше недоступен → будет удалён вместе с entry из WeakMap

🔣 Операции над множествами

В JavaScript теперь есть булевые операции для Set:

const a = new Set([1, 2, 3, 4]);
const b = new Set([3, 4, 5, 6]);

a.union(b); // union() — объединение. Set(6) {1, 2, 3, 4, 5, 6}
a.intersection(b); // intersection() — пересечение. Set(2) {3, 4}
a.difference(b); // difference() — разность. Set(2) {1, 2}
a.symmetricDifference(b); // symmetricDifference() — симметричная разность. Set(4) {1, 2, 5, 6}
a.isDisjointFrom(b); // isDisjointFrom() — проверка, что множества не пересекаются. false
a.isSubsetOf(b); // isSubsetOf() — подмножество. false
a.isSupersetOf(b); // isSupersetOf() — надмножество. false

Оригинал статьи

Подписывайтесь на FrontEndDev чтобы получать больше новостей о web разработке

Иногда бывает нужно подебажить веб приложение прямо на телефоне для чистоты эксперимента. Google Chrome позволяет подключить смартфон и запустить отладку по USB. Вот пошаговый туториал как это сделать.

Для начала скачаем и установим adb (Android Debug Bridge). adb входит в состав platform-tools. Скачать и установить его можно по ссылке (либо через home brew на macOS).
Если у вас установлен Android SDK, то скорее всего adb  уже у вас установлен (если нет, то можно установить его из меню SDK).

После установки проверим, что adb доступен в терминале, выполнив adb.

Теперь докажем вашему смартфону, что вы действительно разработчик. Перейдем в Настройки - О телефоне - Номер сборки и начнем неистово тапать, как будто до листинга хомяка осталось 5 минут. После 10 раза, смартфон вам поверит и скажет, что вы реально разработчик, при этом у вас появится меню Developer Options, где нужно будет найти переключатель USB debugging и включить его.

Отлично, ваш смартфон готов к развлечениям!

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

На смартфоне должен выскочить попап о разрешении дебага по USB - выберите разрешаю, поставив галочку "Всегда разрешать с этого компа".

Ура!

Теперь перейдем на страницу chrome://inspect/#devices. Там отображаются устройства и открытые вкладки на них (офигеем от того, сколько вкладок у нас открыто). Можем перейти в любую и посмотреть, как она работает нативно на устройстве, при этом отображаясь на вашем компьютере.

Но как открыть приложение в процессе разработки, которое запущено на localhost вашего компа?

Для этого пропишем port forwarding (самая верхняя кнопка). Откроем соответствующие настройки и пропишем (например 6006: localhost:6006), и не забудем поставить галочку внизу "использовать port forwarding".

Готово, открывайте http://localhost:6006 на телефоне и дебажьте приложение на компе.

Спасибо за внимание!

Подписывайтесь на каналы в телеграм FrontEndDev и Sleepless Tech чтобы получать больше интересного контента о разработке.

Привет! Вынужден обновить систему на своем vps c Ubuntu 18 на 20. При обновлении по идее все данные должны остаться, по крайней мере в /home директории. Но гарантий, что данные баз данных Mongo и MYSQL, а также данные volume docker контейнеров не будут затронуты - нет.

Поэтому решил забекапить то, что важно.

Mongo

Для того чтобы забекапить все базы из монги, воспользуемся утилитой mongodump (если нужно забекапить конкретную, можно указать --db mydatabasename)

mongodump --host localhost --port 27017 --username adminUser --password MyPassword --authenticationDatabase admin --out ~/projects/mongo_bkp

Можно еще сжать это в архив

mongodump --host localhost --port 27017 --username adminUser --password MyPassword --authenticationDatabase admin --gzip --archive=/path/to/backup/mydatabase.gz

Чтобы накатить бекап, выполним команду:

mongorestore --host localhost --port 27017 --drop ~/projects/mongo_bkp

Кстати chatgpt предлагает сделать автоматическую джобу, которая будет бекапить автоматом данные, с помощью скрипта

#!/bin/bash
TIMESTAMP=$(date +"%F")
BACKUP_DIR="/path/to/backup/$TIMESTAMP"
mkdir -p $BACKUP_DIR
mongodump --host localhost --port 27017 --username adminUser --password MyPassword --authenticationDatabase admin --db mydatabase --out $BACKUP_DIR

Wordpress

Wordpress поднять в докер контейнере, поэтому команда для бекапа будет с использованием докер. Но суть особо не меняется. Будем использовать утилиту mysqldump. При этом можно даже использовать заданные переменные окружения ($MYSQL_ROOT_PASSWORD). Здесь db – это название контейнера.

docker exec db sh -c 'exec mysqldump -uroot -p"$MYSQL_ROOT_PASSWORD" wordpress' > ~/projects/codeart-site/backup/wordpress.sql

Чтобы восстановить данные, выполним команду:

cat ~/projects/codeart-site/backup/wordpress.sql | docker exec -i db sh -c 'exec mysql -uroot -p"$MYSQL_ROOT_PASSWORD" wordpress'

Если вы не задавали имя для базы данных, то можно опустить wordpress в конце.

Контент Wordpress

Данные самого сайта (все загрузки и медиа) можно скачать из docker volume. У меня в docker-compose прописан именной volume для данных wordpress

volumes:
- wordpress:/var/www/html

Посмотрев информацию о volumes docker volume ls , можно понять, что volume называется codeartsite_wordpress. Выполним команду создания временного контейнера, который монтирует codeartsite_wordpress себе и бекапит данные с помощью busybox tar:

docker run --rm -v codeartsite_wordpress:/data -v ~/projects/codeart-site/backup:/backup busybox tar czf /backup/wordpress_content_backup.tar.gz -C /data wp-content

Восстановить данные можно будет командой

docker run --rm -v codeartsite_wordpress:/data -v /path/to/backup:/backup busybox tar xzf /backup/wordpress_content_backup.tar.gz -C /data

Как скачать данные с vps

Скопируем данные на локальную тачку. Есть несколько способов: подключиться через sftp через какой нить TotalCommander или FileZilla, либо использовать консольную команду scp:

scp usename@ip_address:~/projects/codeart-site/backup/wordpress_content_backup.tar.gz  ~/Documents/vps_backup

На этом все! Всем удачи в бекапах и обновлениях!)

Часто хочется иметь налаженный процесс деплоя для своих пет-проектов. С какими-то серьезными инструментами типа Jenkins заморачиваться не хочется. Есть альтернативы: Github Actions | rsync | Dokku. В этой статье расскажу немного про Dokku, о том как настроить и задеплоить свое первое приложение на примере Telegram бота @ytb_cover_bot, который скачивает для вас превьюшку с видео youtube или трека youtube music. Оговорюсь, что для таких приложений (ботов) есть своя специфика, поэтому в конце задеплоим и обычный веб сайт.

Dokku - это инструмент, позволяющий настраивать и деплоить ваши приложения, как если бы вы это делали на Heroku, но только на вашем сервере. Деплой происходит пушем в ремоут ветку dokku (который хостится на вашем сервере) обычной командой git push. При этом логи деплоя можно увидеть сразу в консоли. У dokku вообще много фичей и настроек, я расскажу лишь только о базовой конфигурации, которой мне хватает.

Установка

Установить его можно как standalone приложение, так и в докере. Я выбрал второй вариант (т.к. с первым были ошибки, возможно из-за скромных свободных ресурсов моего сервера) .

Процесс установки описан тут, дублировать, думаю, нет смысла. Обращу внимание, что нужно не забыть открыть порты на вашем сервере, которые определены для dokku контейнера 3022, 8080, 8443.

Первоначальная настройка dokku

На сервере заходим в контейнер (если вы установили в докере, если нет, то выполняйте все команды в обычной консоли):

docker exec -it dokku bash

Можно кстати в алиасы прописать команду:

nano ~/.bash_aliases
alias dokku="docker exec -it dokku dokku" # add this line then re-login with your linux account

Для доступа к приложениям после деплоя для dokku желательно привязать домен (один для всех приложений). Это необязательный шаг, просто это упрощает доступ (проверьте настройки Wildcard domain *.domain.tld A Record у вашего домен провайдера):

domains:add-global jem-art.ru

В итоге приложения будут доступны по адресу scheme://app-name.jem-art.ru

Если вы (как и я) спустя какое то время забыли к какому домену привязали dokku, то можно посмотреть его в конфиге domains для любого из приложений

dokku domains:report app-name

Domains app enabled:           true
Domains app vhosts:            ytb-image-bot.jem-art.ru
Domains global enabled:        true
Domains global vhosts:         jem-art.ru

Теперь сгенерируем ssh ключ на вашем локальном компьютере откуда вы будете деплоить (чтобы абы кто не мог пушить в ваш dokku)

ssh-keygen -f dokku_rsa

Скопируем контент ключа cat dokku_rsa.pub

И добавим его на сервере в dokku

echo "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCs6DIF bla bla bla" | dokku ssh-keys:add dokku_rsa

Т.к. мой dokku запущен под докером, то у меня настроен маппинг портов 3022 (сервер) -> 22 (контейнер) и чтобы зарезолвить такой ssh хост, добавим соответствующий конфиг в ~/.ssh/config на локальном компе:

Host dokku.docker 
HostName 104.131.22.43 
Port 3022  
IdentityFile ~/.ssh/dokku_rsa

Создание приложения

Наконец создадим наше приложение ytb-image-bot

dokku apps:create ytb-image-bot

Теперь добавим remote в git

git remote add dokku dokku@dokku.docker:ytb-image-bot

Теперь при выполнении git push dokku master у нас будет стартовать деплой и перезапуск приложения. Стартанем его чуть позже, а пока добавим еще некоторые настройки.

В репозитории приложения добавим Procfile для того, чтобы описать какую команду надо выполнить чтобы запустить приложение. Т.к. у меня telegram бот, а не веб-сервер, то я добавляю worker: worker: yarn start

Если бы это был веб-сервер, то нужно было бы добавить директиву web - при этом dokku автоматически делает мапинг портов на порт 5000 для вашего приложения (поэтому если не хочется добавлять какие то доп переменные окружения, то лучше чтобы сервер слушал порт 5000).

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

dokku ps:scale ytb-image-bot worker=1

Добавим нужные env переменные командой с флагом --no-restart через пробел (без флага dokku будет пытаться перезапустить приложение которого еще нет и в итоге так и не проставит переменные)

dokku config:set ytb-image-bot --no-restart TG_TOKEN=YOUR_TOKEN MONGOURL=mongo://blabla21

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

По дефолту dokku во время деплоя не останавливает предыдущую версию приложения, но у меня telegram бот, который работает по long-polling. И если будет запущено 2 инстанса с одним и тем же ключом, то будут сыпаться ошибки, и в итоге dokku прервет деплой новой версии. Для этого выключим zerodowntime

dokku checks:disable ytb-image-bot

Для обычных веб приложений zerodowntime, конечно, топ фича.

Вот и все, делаем комит и пушаем его в dokku git push dokku master

Результат деплоя в консоли. Т к у нас не web-приложение, то https://ytb-image-bot.jem-art.ru/ у нас не отвечает. Зато отвечает @ytb_cover_bot 😊 (как и @aiko_tiktok_download_bot, который деплоится таким же способом).

Деплоим веб-приложение

Отличий для веб не так много.
Создаем проект на сервере так же как и предыдущий:

dokku apps:create web-test

На локальном компе добавляем ремоут:

git remote add dokku dokku@dokku.docker:web-test

Добавляем Procfile с директивой web: web: yarn start или web: node index.js

Пушаем git push dokku master

Наслаждаемся результатом 😊 (я ленивая жопа не сделал сертификаты для * доменов, но по http работает) .

Подписывайтесь на мой канал в Telegram, где я рассказываю про разработку и не только.
Всем удачи ✌️

Или почему я не любил работать с certbot.

По своей натуре, я человек очень торопливый. Если можно что-то сделать быстро и не вникая в суть (по какому нибудь туториалу например), то я только рад. Сделал и забыл и желательно не думать что когда то придется это делать опять. Однако, часто случается так, что у меня какая то особая ситуация в плане конфигурации сервера и приложений на нем, как например вот эта.

Есть docker контейнер с wordpress и docker контейнер с nginx. Работают они независимо, так сложилось исторически. И когда-то как-то я выпустил сертификаты letsencrypt и вот пора выпускать их снова. Так в чем проблема?

Непонимание где лежат эти сертификаты сейчас и откуда они берутся.

Так вышло что сертификаты были выпущены при помощи docker контейнера certbot. И жонглированием волюмами и файлами между ними (для меня) становится уже очень сложным. Надо как-то перекинуть файлы сертификатов (проставив нужные пермишены и сохранить ссылки на файлы ключей) между вольюмами контейнеров certbot и nginx. Каким-то образом я это сделал и уже не помню как.

Непонимание работы certbot

При попытке нахрапом быстренько обновить серты, получаешь ошибки, значения которых нужно разбирать с гуглом или чатом гпт. + еще добавляется конфиг докер компоуза для nginx + сам конфиг nginx + еще настройка шаринга volume между контейнерами. ТЬМА!

Сейчас попробуем остановиться и разложить немного по полкам.

Есть конфиг docker-compose для сайта на wordpress:

version: '3'

services:
  db:
    image: mysql:8.0
    container_name: db
    restart: unless-stopped
    env_file: .env
    environment:
      - MYSQL_DATABASE=wordpress
    volumes:
      - dbdata:/var/lib/mysql
    command: '--default-authentication-plugin=mysql_native_password --table-definition-cache=200'
    networks:
      - app-network
    cap_add:
      - SYS_NICE

  wordpress:
    depends_on:
      - db
    image: wordpress:5.1.1-fpm-alpine
    container_name: wordpress
    restart: unless-stopped
    env_file: .env
    environment:
      - WORDPRESS_DB_HOST=db:3306
      - WORDPRESS_DB_USER=$MYSQL_USER
      - WORDPRESS_DB_PASSWORD=$MYSQL_PASSWORD
      - WORDPRESS_DB_NAME=wordpress
    volumes:
      - wordpress:/var/www/html
      - ./uploads.ini:/usr/local/etc/php/conf.d/uploads.ini
    networks:
      - app-network

volumes:
  wordpress:
  dbdata:

networks:
  app-network:
    driver: bridge

Где мы видим, что есть volume wordpress. Запомнили.

Есть конфиг docker-compose для nginx:

version: '3'
services:
  web:
    image: nginx-ssl-preread
    volumes:
      - codeartsite_wordpress:/var/www/html
      - /etc/letsencrypt:/etc/letsencrypt
      - ./nginx.conf:/etc/nginx/nginx.conf
      - ./conf.d:/etc/nginx/conf.d
      - ./modules-enabled:/etc/nginx/modules-enabled
    ports:
      - "80:80"
      - "4443:4443"
      - "8444:8444"
      - "1337:1338"
    networks:
      - codeartsite_app-network
    command: [nginx-debug, '-g', 'daemon off;']

volumes:
  codeartsite_wordpress:
    external: true

networks:
  codeartsite_app-network:
    external: true

У него есть мапинг codeartsite_wordpress:/var/www/html.

Это значит, что volume wordpress, объявленный в проекте codeartsite мапится внутри контейнера по пути /var/www/html. Запомнили.

И финально, есть конфиг для самого nginx:

server {
    listen 80;
    listen [::]:80;
    client_max_body_size 12m;
    server_name jem-art.ru www.jem-art.ru;

    location ~ /.well-known/acme-challenge {
        allow all;
        root /var/www/html/wordpress;
    }

    location / {
        rewrite ^ https://$host$request_uri? permanent;
    }
}

Что тут интересного?  location ~ /.well-known/acme-challenge- эта директива отвечает за проверку сертификата при выпуске.

Т е, когда вы попросите certbot выпустить сертификат для вашего сайта командой

sudo certbot certonly --webroot -w /var/www/html/ --email test@gmail.com --agree-tos --no-eff-email -d jem-art.ru -d www.jem-art.ru

То после выпуска, перед тем как положить сертификаты по пути /etc/letsencrypt/..., certbot положит какой то ключ (не уверен какой, может и сам сертификат, не суть) по пути /var/www/html, и пойдет проверять его запросом на http://jem-art.ru/.well-known/acme-challenge, а ваш nginx должен будет ответить на этот запрос.

Вот тут и первая моя проблема. Я получаю 404 на этот запрос.

Domain: www.jem-art.ru
  Type:   unauthorized
  Detail: 104.248.43.82: Invalid response from http://www.jem-art.ru/.well-known/acme-challenge/P0hEw2RfnX8gJYFwTz-NzRTbBYOwiUmbHhE7gpVqaC0: 404

Первая ошибка - директория /var/www/html/ не смонтирована в контейнер nginx. Я что-то кладу в  /var/www/html/ , а в nginx это не появляется. Все верно, как мы помним nginx раздает у себя все, что лежит в codeartsite_wordpress. Как найти папку на диске у этого volume? Несложно

docker volume ls - список всех волюмов (видим наш)

docker volume inspect codeartsite_wordpress - смотрим детали

А вот и "Mountpoint": "/var/lib/docker/volumes/codeartsite_wordpress/_data"

Да, наверно, не совсем красиво, но будем указывать этот путь для certbot.

Вторая ошибка - тупо нет директории wordpress при обращении к /var/www/html/wordpress в nginx. Просто оставим /var/www/html/

location ~ /.well-known/acme-challenge {
        allow all;
        root /var/www/html;
    }

Получаем следующую ошибку:

archive directory exists for jem-art.ru

Это значит, что есть папка archive у letsencypt и в ней есть ключ для сайта jem-art.ru. Значит надо не заново получать сертификат, а обновлять его. Но т.к. я что-то там крутил-вертел, в папке renewal для данного сайта нет нужного конфига, поэтому просто вызывам насильно получение нового сертификата (потом его можно будет обновить, просто вызвав certbot renew).

sudo certbot certonly --webroot -w /var/lib/docker/volumes/codeartsite_wordpress/_data --email test@gmail.com --agree-tos --no-eff-email --force-renewal -d jem-art.ru -d www.jem-art.ru --force-renewal

Готово! Сертификаты в нужной директории. Перезапускаем nginx в докере и наслаждаемся.

Ну а по-хорошему добавим задачу в crontab:

30 2 1 */3 * /usr/bin/certbot renew --quiet --deploy-hook "/home/jem/projects/nginx/restart.sh"

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

Привет.
Ни с чего в голове промелькнуло какое-то воспоминание иероглифов написанных в столбик. Видимо, на востоке надписи иногда или часто располагают вертикально. Для человека не особо знакомого с востоком для меня иероглифы это просто набор черточек.

В погоне за своей визуализацией накидал скетч с добавлением случайных величин. Каждая линия была короткой и располагалась в сетке с небольшим случайным отклонением и поворотом на случайный угол. Я решил использовать три основных цвета — красный, синий и желтый, чтобы создать яркий и динамичный узор. При этом я решил еще поэкспериментировать и сделал несколько вариаций.
Первая вариация, когда один цвет полностью заполняет пространство, второй - заполняет его на 2/3, а третий на 1/3.
Во второй я добавил большую вариативность по вертикали в левой части и меньше в правой.
Третья - заполнение черточек по ячейкам сетки в таком же соотношении цветов. Но если ячейка уже была занята цветом, то ее уже занять другим цветом нельзя.
Еще одна была связана с ошибками в алгоритме, что тоже было интересно.

Как результат, еще одна серия картин.

Возможно стоит еще поиграться с цветами и размером. А пока слепил небольшой ролик с рендерингом скетча.

Еще больше контента связанного с generative art можно найти у меня в Telegram, Instagram и Twitter.

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

Разработка ботов тема не новая и затертая до дыр. В сети полно туториалов как сделать простого Телеграм-бота или не простого, и каждый спикер предлагает какой-то свой подход. Ведь, действительно, один и тот же функционал можно реализовать по-разному. И, к сожалению, каких-то best practices по разработке ботов я не нашел, а смотреть кучу уроков - времени не напасешься. Поэтому я решил сам искать решения и подходы, которые можно было бы переиспользовать в дальнейшем.
Как в итоге это работает, можно посмотреть в боте АстроКот (есть демо подписка на 7 дней)

Пару слов о Telegraf.js.

Когда я только начинал разрабатывать своих ботов для пет-проектов, я писал с минимальным набором библиотек, даже без telegram-node. И в этих проектах мне приходилось при вызове каждого обработчика пользовательского ввода или реакции устанавливать обработчик, который будет отлавливать следующий ввод. Много когда, очень неудобно, просто запутаться. Эта задача отлично решается с помощью подхода конечных автоматов (FSM). Для следующих проектов я использовал уже XState. И недавно наткнулся на Telegraf.js, который предлагает функционал FSM (реализованный при помощи сцен), совместно с Telegram Bot API. В общем - это то, что нужно. Плюс, есть возможность подключать различные middleware (как в Express), чем мы потом и будем пользоваться.

Задача

Пишем бота, который присылает каждый день гороскоп, а так же предоставляет пользователям возможности:

• посмотреть разные виды гороскопов,
• сделать расклад Оракула,
• выполнить запрос ко Вселенной,
• заговор на деньги,
• настроить бота под себя - настроить локальное время, время уведомлений,
• и конечно ОФОРМИТЬ ПОДПИСКУ!

Без паники, обо всем в подробностях я рассказывать не буду. Хотелось бы сфокусироваться на том функционале, который можно вынести в шаблон для бота, на основе которого уже можно реализовывать любую предментную область.
Что должно быть в шаблоне:

• сохранение состояния пользователя и его восстановление при общении с ботом (на случай перезапуска бота при деплое)
• возможность взаимодействия пользователя с некими глобальными сообщениями, которые выбиваются из стандартного флоу общения пользователя с ботом (запрос-ответ)
• возможность для пользователя работать с reply клавиатурой, которая всегда доступна
• реализация удобного интерфейса оплаты подписки
• сбор метрик
• реализация возможности приема обращений пользователей о багах

Быстрое введение в создание бота на Telegraf.js

Создаем бота let bot = new Telegraf(token);

При помощи use мы можем добавлять различные middleware, которые будут выполняться в том порядке, в котором их добавили. Например можем добавить сессии для пользователей, в которых будем хранить какую то информацию (в объекте ctx.session, который доступен для записи и чтения), связанную со сценой, в которой находится пользователь.
bot.use(session())

Мы можем навесить обработчики комманд (сообщений от пользователя которые начинаются с /) при помощи
bot.command('subscription', async (ctx) => {...})

Обработчик сообщения
bot.on(message("text"), async (ctx) => {...});

Oбработчик нажания по колбек кнопке
bot.on(callbackQuery(), async (ctx) => {...});

Можем переводить пользователя в определенную сцену. Например создадим сцену отображения гороскопов и при клике на кнопку переведем пользователя в нее.

const horoMainScene = new Scenes.BaseScene("horoMainScene");

horoMainScene.enter(async (ctx) => {
    ///обработчик, вызываемый, когда пользователь зашел в хату сцену
    /// можем тут проверить подписку пользователя или запросить данные гороскопов и вывести
})

bot.on(callbackQuery(), async (ctx) => {...
    await ctx.scene.enter("currentHoroScene");
});

Сцены подключаются как middleware в бот this.bot.use(getStage().middleware());

где функция getStage() возвращает все сцены для бота

Фичи

Сохранение стейта пользователя.

Фича важная, как по мне, на случай, если приложение упало или ты его деплоешь не с zero downtime. После того как бот поднялся, пользователь может общаться с ботом дальше как ни в чем не бывало (а не тыкаться и в итоге слать /start, чтобы начать общение с начала), потому что хендлеры обработки пользовательского инпута восстановились на той же сцене, где и был пользователь.

Для этого в обработчике входа в сцену ( scene.enter(() => {}) ) в самом конце добавляем сохранение всего объекта ctx.session и имени сцены. Почему в конце - чтобы знать, что сцена обработалась без ошибок и можно сохранять пользователя тут. ctx.session и имя сцены - полная информация, которая нам поможет восстановить позицию пользователя. Возможно, сохранение можно добавить и каких то особых случая, например, когда обработка нажатия на кнопку, не уводит пользователя в другую сцену, но меняет какое-то состояние.

У Telegraf.js есть возможность хранения сцены в Redis или другиe бд в разных форматах (например с middleware session-local). Я же сделал свой велосипед с хранением данных в mongoDB, т к и остальные данные тоже хранятся в монге. Если бот не использует бд, то можно было бы обойтись и session-local.

Сама реализация:

saveState(ctx, "horoMainScene");

///
async function saveState(ctx, scene) {  
    let { session = {} } = ctx;  
    let { __scenes, ...rest } = session;  
    let userId = ctx.chat.id;  
    return saveUserState(userId, scene, JSON.stringify(rest));
}
///

async function saveUserState(userId, scene, session) {  
    const newUser = new UserStateModel({    
        userId,    
        scene,    
        session: JSON.stringify(session),  
    });  
    await newUser.save();
}

Как восстановить состояние пользователя?

Для этого мы подключаем свой middleware:

async function restoreState(ctx, next) {
  if (
    ctx.update &&
    ctx.update.message &&
    ctx.update.message.text &&
    ctx.update.message.text.startsWith("/")
  ) {
    /// значит это сообщение с командой, а значит данные сцены восстанавливать не нужно, потому что команды отрабатывают глобально
    return next();
  }

  if (!ctx.scene.current) {
  // у пользователя нет текущей сцены. В работе нашего бота такого быть не может, значит нужно восстановить сцену из бд

    let userState = await getState(ctx);
    
    if (userState) {
      const scene = userState.scene; // имя сцены
      let currentScene = ctx.scene.scenes.get(scene);
      if (!currentScene) {
        return next();
      }
      
      let currentHandler = currentScene.handler; // текущий хендлер сцены
      ctx.session = JSON.parse(userState.session);

      await ctx.scene.enter(scene, {}, true); // входим в сцену бесшумно (т е без вызова обработчика enter)
      
      currentHandler(ctx, next); // после восстановления вызываем текущий обработчик апдейта от юзера
      return;
    }
    return next();
  }
  return next();
} 

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

getState() получает стейт пользователя из бд. Из списка сцен (который всегда доступен через `ctx.scene.scenes`)бота получаем текущую сцену со всеми ее параметрами и устанавливаем ее для пользователя. Сделать это надо так, что бы функция enter для данной сцены не выполнялась, потому что пользователь в своем флоу уже находится в ней и будет странным если он опять получит сообщения которые отправляются при заходе в сцену или выполняется какая-нибудь другая обработка. Для этого существует 3й параметр в функции ctx.scene.enter(scene, {}, true) - silen = true.

А после того, как мы восстановили стейт и сцену, вызываем handler текущей сцены, который обработает текущий update от пользователя (нажатие по callback кнопке или текстовый инпут), который не был обработан, т к у пользователя не было сцены (и соответственно не было назначено никаких обработчиков).
Не забудем вызвать next() на остальные ветки проверок, чтобы вызвать следующие middleware, если они есть или будут.

Возможность взаимодействия с глобальными сообщениями бота

Было бы довольно просто работать по обычному флоу с пользователем в формате запрос - ответ. Когда бот ожидает какой нибудь инпут от юзера и выдает ответ, переводя пользователя в какую-то сцену, где есть только несколько вариантов развития событий (переходов в другие сцены). Но задача усложняется тем, что пользователю могут приходить сообщения от бота по расписанию. Например гороскоп - сообщение с кнопкой, позволяющей посмотреть гороскопы на различные тематики и дни. Либо сообщение с предложением продлить подписку. И пользователь должен мочь перейти по этой кнопке, а должен мочь проигнорировать сообщение и продолжить свой флоу, где он может быть например в процессе настроек или использования другого функционала.

Для этого нам нужно определить круг возможных callbackQuery (реакций на кнопки - т е id кнопки, которая была нажата), на которые мы можем реагировать глобально. В данном боте это всего несколько вариантов: otherHoro, renewSubscription, toMainGlobal - это уникальные id кнопок для глобальных сообщений.

Далее, создаем middleware для проверки этих апдейтов от бота. Подключаем его после middleware со всем сценами. Т е если такой апдейт не заинтересовал ни один обработчик из сцен и он попадает в этот middleware, возможно тут будет хендлер для него.

В Telegraf.js есть удобный класс Composer, в котором при помощи метода use можно подключить наши глобальные обработчики как middleware. Получается мидлвары в мидлваре (привет Нолану).

При этом сразу проверим ветку, что если наш апдейт от юзера это не callbackQuery - то пропустим наши обработчики и вызовем следующий middleware через next(). Для этого используем функцию Composer.branch:

const globalCallbackQueryComposer = new Composer();
globalCallbackQueryComposer.use(otherHoroGlobalCallbackHandler);
globalCallbackQueryComposer.use(renewSubscriptionHandler);
globalCallbackQueryComposer.use(toMainGlobalHandler);

let globalCallbackMiddleware = Composer.branch(
  (ctx) => {
    return ctx.callbackQuery;
  },
  globalCallbackQueryComposer,
  async (ctx, next) => {
    await next();
  }
);

Пример реализации одного из глобальных обработчиков

async function otherHoroGlobalCallbackHandler(ctx, next) {
  const answer = ctx.callbackQuery.data;
  if (answer === controls.otherHoro) {
    ctx.session.fromGlobal = true;
    await ctx.scene.enter("horoMainScene");

    answerButtonCb(ctx);
    await next();
    return;
  }
  await next();
}

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

Возможность для пользователя работать постоянно с reply клавиатурой

Вообще, хотелось бы убирать клавиатуру при выборе определенного меню. НО! Это нужно делать отдельным сообщением (отправляешь сообщение с типом клавиатуры removeKeyboard), потому как невозможно например отправить сообщение с колбек клавиатурой и одновременно удалить reply клавиатуру - такие ограничения у Telegram Bot API. Либо редактировать клавиатуру сообщения, на котором эта клавиатура задавалась (у меня что-то так не завелось). Поэтому я решил не париться (по этому поводу, а париться по другому).

Для этого сделаем мидлвар, который будет отслеживать reply апдейты от пользователя (который по факту - просто текст, поэтому они тоже должны быть уникальными, например ⚜️ Оракул).

const { Composer } = require("telegraf");
const { mainMessageGlobalHandler } = require("../scenes/main");

class GlobalInlineKeyboardHandler {
  constructor(callback) {
    this.callback = callback;

    const globalInlineKeyboardComposer = new Composer();
    globalInlineKeyboardComposer.use(callback);

    this.globalInlineMiddleware = Composer.branch(
      (ctx) => ctx.update && ctx.update.message,
      globalInlineKeyboardComposer,
      (ctx, next) => {
        next();
      }
    );
  }

  middleware() {
    return this.globalInlineMiddleware;
  }
}

let globalInlineMiddleware = new GlobalInlineKeyboardHandler(
  mainMessageGlobalHandler
).middleware();

Сам же обработчик выглядит так

async function mainMessageHandler(ctx, next) {
  if (ctx.update.message.text === buttons.settings) {
    await ctx.scene.enter("settingsMainScene");
    return;
  }
  if (ctx.update.message.text === buttons.horo) {
    await ctx.scene.enter("horoMainScene");
    return;
  }
  if (ctx.update.message.text === buttons.request) {
    await ctx.scene.enter("universeScene");
    return;
  }
    .....
    ....
    ...
}

Выбираем Запрос ко Вселенной. Потом с помошью reply клавиатуры выбираем Гороскопы.

Сделаю небольшое отступление по поводу вызова next(). Вообще, всю работу с обработкой сообщений в Telegraf.js нужно воспринимать как работу с middleware. Но часто, когда дело доходит до сцен или обычных обработчиков, многие забывают о том, что ваш обработчик - это middleware, у которого вторым агрументом приходит next. Даже в примерах часто на это забивают. И часто кажется, что ты обработал апдтейт от юзера, а дальше хоть трава не расти. В случаях со сложной логикой это может быть чревато долгим поиском багов. Но вместо того чтобы постоянно бдить за тем "а не забыл ли я во всех ветках обработчика вызвать next?", можно сделать какой нибудь класс обертку

class BotScene {
  constructor(name) {
    this.name = name;
    this.scene = new Scenes.BaseScene(name);
  }

  onEnter(...middlewares) {
    this.scene.enter(...createMiddlewres(middlewares));
  }

  onAction(action, ...middlewares) {
    this.scene.action(action, ...createMiddlewres(middlewares));
  }

  on(actionType, ...middlewares) {
    this.scene.on(actionType, ...createMiddlewres(middlewares));
  }

  onCallbackQuery(...middlewares) {
    this.scene.on(callbackQuery(), ...createMiddlewres(middlewares));
  }

  onMessage(...middlewares) {
    this.scene.on(message("text"), ...createMiddlewres(middlewares));
  }

  getScene() {
    return this.scene;
  }
}

Здесь я определил класс, с возможностью добавить обработчики на вход в сцену, обработчики текстового инпута, callbackQuery, а также общий обработчик on, через который можно подрубить коллбек на любой апдейт. Аргументов может быть много, потому что перед основным коллбеком можно вызвать другие, которые добавляют какую-нибудь информацию в сессию или делают какую-то другую обработку перед основным коллбеком. Эти функции обязательно заканчиваются вызовом next(), иначе не добраться до основного обработчика, поэтому тут ошибиться трудно.

Последняя же функция оборачивается в другую, которая явно вызывает next(), на всякий случай в блоке try catch, если обработчик next был вызван в вашей функции (двойной вызов next приведет к исключению)

function nextCallWrapper(cb) {
  return async (ctx, next) => {
    await cb(ctx, next);
    try {
      await next();
    } catch {}
  };
}

function createMiddlewres(middlewares) {
  let lastCallback = middlewares.pop();
  let mainCallback = nextCallWrapper(lastCallback);
  return [...middlewares, mainCallback];
}

Также, нужно учесть, что этот middleware подключается после middleware сцен (порядок важен), и если в текущей сцене есть обработчик тестового ввода, то он первый перехватит сообщение юзера, если это будет нажатие по кнопки reply клавиатуры (нажатие по факту просто отправляет текст в чат). Для этого можно при подписке на текстовое сообщение в сцене добавить обработчик сообщений клавиатуры, и если это сообщение матчится с какой-нибудь из кнопок, то не вызывать метод next, чтобы не прокидывать сообщение в обработчик сцены. И конечно здесь есть нюанс. Например, если у вас есть другие middleware кроме сцен, в которые должны прокидываться апдейты после обработки в сценах. Как быть, если не вызывая метод next, обработка дальше не пойдет. Как вариант - реализовать обработку глобальных сообщений клавиатуры не как middleware перед основной фукнцией сцены, а как обертку (high ordered function) над основной функцией сцены. Т е обертка проверяет матчится ли сообщение с какой-нибудь из кнопок, если да – обработать как нажатие на кнопку и вызвать метод next, если нет – вызвать главную функцию сцены, и тоже вызвать next.

import globalInlineHanler from ......


function withGlobalInlineHandler(cb) {
  return async (ctx, next) => {
    let isKeyboardProcessed = await globalInlineHanler(ctx, next); // должен вернуть  true/false в зависиимости от того, обработан апдейт как нажатие по кнопки или нет (при этом функция сама внутри вызовет next()) 
    if(!isKeyboardProcessed) {
        await cb(ctx);
        await next();
    }
  };
}


/// подключение

someInputScene.onMessage(withGlobalInlineHandler((ctx) => {
    /// ваша обработка текстового инпута
})

А если логика с обработкой остальными middleware не так важна (т е не обязательно, чтобы апдейт всегда прокидывался во все middleware до конца), то можно вызывать вот так

fucntion globalInlineHanler(ctx, next){
	if(ctx.update.message.text === 'Кнопка 1') {
    /// если это глобальная кнопка
    	ctx.scene.enter('Имя сцены 1');
        return;
    }
    ///если нет - прокидываем в основной текстовый обработчик сцены
    next()
} 




import globalInlineHanler from ......

/// подключение

someInputScene.onMessage(globalInlineHanler, (ctx, next) => {
    /// ваша обработка текстового инпута
})

Реализация удобного интерфейса оплаты подписки

Самый удобный способ оплаты подписки, конечно, через TelegramPaymentAPI. Но в текущих реалиях подключить его я не смог - ни один провайдер (я пробовал целых) не предоставляют прием платежей по картам через TelegramPaymentAPI (а счастье было так близко).
Пришлось придумывать что-то свое. Многие боты делают так - генерят ссылку для оплаты через ТинькофPay или Юкассу (вшивая там какие-нибудь данные по юзеру, чтобы можно было отследить кто оплатил), юзер переходит по ссылке, оплачивает, а потом в боте просят юзера нажать кнопку "Я оплатил". Выглядит ужасно, как по мне (но надежно).

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

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

Приведу полный код модуля оплаты

const axios = require("axios");
const { v4 } = require("uuid");
const PaymentServer = require("./payment-callback-server");

const API_URL = "https://api.yookassa.ru/v3/payments";
const PAYMENT_BASE_URL =
  "https://yoomoney.ru/checkout/payments/v2/contract/bankcard?orderId=";

class UkassaPaymentService {
  constructor(providerConfig) {
    this.token = providerConfig.secretKey;
    this.shopId = providerConfig.shopId;
    this.paymentServer = new PaymentServer(5023, "/result-payments");
    this.paymentServer.startServer();
  }

  createAuthHeader() {
    return `Basic ${Buffer.from(`${this.shopId}:${this.token}`).toString(
      "base64"
    )}`;
  }

  async createInvoice(amount, currency, description, userId) {
    let paymentInfo = {
      amount: {
        value: amount,
        currency: currency,
      },
      payment_method_data: {
        type: "bank_card",
      },
      confirmation: {
        type: "redirect",
        return_url: "https://t.me/cute_astro_bot",
      },
      capture: true,
      description,
      metadata: {
        userId,
      },
    };

    try {
      let result = await axios.post(API_URL, paymentInfo, {
        headers: {
          Authorization: this.createAuthHeader(),
          "Idempotence-Key": v4(),
          "Content-Type": "application/json",
        },
      });
      let invoice = result.data;
      return {
        url: `${PAYMENT_BASE_URL}${invoice.id}`,
        invoice,
      };
    } catch (e) {
      console.log("error with invoice cration");
      console.log(e);
      return null;
    }
  }

  subscribeOnSuccessPayment(handler) {
    this.paymentServer.attachPaymentHandler(handler);
  }

  async checkPaymentIsDone(paymentId) {
    const url = `${API_URL}/${paymentId}`;
    try {
      let result = await axios.get(url, {
        headers: {
          Authorization: this.createAuthHeader(),
        },
      });
      return {
        isDone: result.data.status === "succeeded",
        invoice: result.data,
      };
    } catch (e) {
      console.log(e);
      return { isDone: false };
    }
  }
}

module.exports = {
  UkassaPaymentService,
};

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

checkPaymentIsDone - как раз возможность проверки платежа по кнопке.

PaymentServer - обычный http server, который через nginx привязан к домену моего сайта, для которого офомлена Юкасса. Юкассу оформил для продаж через интернет магазин, потому как для ботов оплату по карте они не подключают, а для сайта - подключают. Но там протокол не подходящий для того, чтобы можно было нативно это привязать к TelegramPaymentAPI (я проверял).

function createServer(paymentEndpoint, port, handlers = []) {
  const server = http.createServer((req, res) => {
    // Handle only POST requests
    if (req.method !== "POST") {
      res.writeHead(405, { "Content-Type": "text/plain" });
      res.end("Method Not Allowed");
      return;
    }

    let body = "";
    req.on("data", (chunk) => {
      body += chunk.toString();
    });

    req.on("end", async () => {
      const { pathname, query } = url.parse(req.url);
      const queryParams = querystring.parse(query);
      // Check if the request is for the specified endpoint
      if (
        pathname !== paymentEndpoint ||
        req.headers["content-type"] !== "application/json"
      ) {
        res.writeHead(404, { "Content-Type": "text/plain" });
        res.end("Not Found");
        return;
      }
      try {
        const payment = JSON.parse(body);
        console.log("Received JSON data:", payment);
        handlers.forEach(async (handler) => {
          try {
            await handler(payment);
          } catch {}
        });
        // Send a response
        res.writeHead(200, { "Content-Type": "application/json" });
        res.write(
          JSON.stringify({
            success: true,
          })
        );
        res.end();
      } catch (error) {
        res.writeHead(400, { "Content-Type": "application/json" });
        res.end(JSON.stringify({ success: false }));
      }
    });
  });

Не забудьте проверить, что не абы кто шлет запрос на ваш эндпоинт :)

Возможности приема обращений пользователяей о багах

Можно завести отдельного бота под это дело, и это даже удобнее. Но тогда есть вариант закапаться в жонглировании ботами. Поэтому я реализовал это простым сохранением обращения в БД и уведомлением админа (или админов). У админа же есть свой админский функционал в том же самом боте. Реализовать админский функционал просто, при помощи мидлвары от Telegraf.js

this.bot.use(Composer.acl([admin_id], adminBot));

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

let adminBot = new Composer();


adminBot.command("user", (ctx) => {
  ctx.scene.enter("mainScene");
});

....... остальные обработчики, мидлвары и подписки.

adminBot.on(message("text"), mainGlobalMessageHandler);

module.exports = {
  adminBot,
};

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

Хотелось бы еще прикрутить сбор метрик в Grafana с помощью Prometheus, но боюсь для моего VPS с 1 GB RAM это немного жирно.

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

function createCallbackMarkup(buttonsArray) {
  let allowedReply = {};
  let keyboard = buttonsArray.map((item) => {
    return item.map((button) => {
      let text;
      let data;
      let hide = false;
      if (Array.isArray(button)) {
        [text, data, hide = false] = button;
      } else {
        ({ text, data, hide } = button);
      }
      allowedReply[data] = true;
      return Markup.button.callback(text, data, hide);
    });
  });
  return {
    keyboard,
    allowedReply,
  };
}

let { keyboard, allowedReply } = createCallbackMarkup([
    [["🌔 Ваше прошлое", controls.past]],
    [["✨ Ваше настоящее", controls.present]],
    [["🔮 Ваше будущее", controls.future]],
    [["Не смотреть", controls.cancel]],
  ]);
  setAllowedReply(ctx, allowedReply);
.
.
.
function setAllowedReply(ctx, reply) {
  ctx.session.allowedReply = reply;
}

function withAllowedCb(handler) {
  return async (ctx, next) => {
    if (
      ctx.session.allowedReply &&
      ctx.callbackQuery &&
      ctx.callbackQuery.data
    ) {
      let action = ctx.callbackQuery.data;
      if (!ctx.session.allowedReply[action]) {
        return next();
      }
    }
    await handler(ctx, next);
  };
}

usersMainScene.onCallbackQuery(
    withAllowedCb(async (ctx, next) => {
      /// гарантировано данные callbackQuery из тех, что разрешены
      clearAlloweReply(ctx)
    })
)

UPD

Пока писал статью, понял что механика с reply клавиатурой ужасная. Несмотря на то, что сама клавиатура скрывается автоматически после первого нажатия, вместо нее вылезает дефолтная клавиатура смартфона. Закрывая ее, мы опять видим reply клавиатуру. И только закрыв ее вручную можно видеть полный чат общения с ботом. Это очень неудобно, особенно, когда сообщения от бота могут занимать целый экран смартфона.
Я отказался от нее и теперь использую inline клавиатуру на самом сообщении.

На этом  и закончились решения к которым я пришел. Часть из них, возможно, являются велосипедами. Если захотите дать какой-нибудь комментарий - велкам в мой телеграм канал SleeplessTech.

В следующей статье расскажу, как это всё деплоится на сервер с помощью Dokku.