OneCode

Хороших выходных, ребят! 🤙 @onecode_blog

Доверяй ИИ, но проверяй! 😅

Серверы и масштабирование Часть 3 Мониторинг В крупных и важных приложениях нужен хороший мониторинг, чтобы мы могли легко оценить текущее состояние системы, определить узкие места и вовремя реагировать на возможные неприятности. В базовом варианте мониторингом может служить панель сервер-провайдера, то есть сервиса, где вы покупаете серверы - там обычно есть базовые графики потребления памяти, процессора и диска. Можно настроить уведомления о привышении нагрузки, например когда потребление памяти превышает 80% мы получим письмо на email. Это удобно и всегда нужно сразу настраивать такие уведомления. Однако для более крупных приложений хочется видеть больше данных. Кроме нагрузки на сам сервер важно отслеживать работу отдельных процессов, таких как Nginx, PHP-FPM и базы данных. Например для Nginx полезно видеть количество запросов, время отклика, количество открытых соединений и тд. Для PHP-FPM тоже количесто запросов, время обработки запроса, потребление памяти и тд. Для PostgreSQL или MySQL тоже количество запросов, время работы запросов, потребление ресурсов и тд. Для решения этой задачи есть разные способы, но оптимальный с точки зрения простоты настройки, надежности и полноты я считаю связку Prometheus + Graphana. Можно сказать, что это классический популярный вариант. Обычно они вместе ставятся на отдельный небольшой сервер. Prometheus Как я сказал, прометеус в идеале устанавливается на отдельный сервер и собирает необходимые данные с остальных серверов, сохраняя их в свою внутреннюю базу данных. Настройка прометеуса довольно проста - там есть файл конфигурации prometheus.yml, в котором мы указываем какие метрики, с каких серверов и с какой периодичностью необходимо получать. Помимо этого на каждый сервер, с которого прометеус должен собирать метрики, необходимо установить экспортер - небольшая программа, которая получает данные от нужного процесса и передаёт их в прометеус. Например, если мы хотим собирать метрики Nginx, то нужно установить nginx-prometheus-exporter, для PHP-FPM устанавливаем php-fpm_exporter, для PostgreSQL ставим postgres_exporter и так далее. Экспортеры работают на нужных серверах, собирают данные в нужном для прометеуса формате, при этом потребляют незначительное количество ресурсов сервера. Прометеус опрашивает экспортеры с указанной нами периодичностью (например раз в 15 минут) и хранит эти данные у себя. Всё просто. Graphana Графана нужна для отображения данных из прометеуса в графическом интерфейсе. В графане мы можем создавать различные информационные панели с графиками на основе данных из прометеуса, выдавать к ним доступ и настраивать уведомления (alerts). Например, можно создать панель, отображающую количество запросов в секунду (RPS) для Nginx, время отклика PHP-FPM, использование CPU и памяти сервером и т.д. Таким образом анализируя метрики в Graphana, собранные Prometheus, можно выявлять узкие места в производительности и принимать решения о масштабировании или оптимизации инфраструктуры и своевременно получать уведомления, когда что-то идёт не так. Спасибо за внимание и репосты, парни! @onecode_blog 👈

Серверы и масштабирование Часть 2 Вчера говорили про серверы, на которых работает наше приложение. Их может быть от 1 до бесконечности, а в нашем примере их было два + балансировщик нагрузки, который скрывает всю эту кухню, позволяя нам спокойно проводить свои эксперименты за его кулисами 😈 И опциональный вебсокет-сервер для реалтайм обновлений. Сегодня говорим про базы данных. У нас может быть несколько баз данных. В моих проектах их две - реляционная (PgSQL) для основных данных приложения и NoSQL (Redis) для кеширования, сессий и задач в очереди. Реляционная база данных В нашем примере я выношу основную базу на отдельный сервер. Это нужно потому что все серверы, на которых работает наше приложение должны работать с одной базой данных. Соответственно наши application серверы и worker сервер подключаются к отдельному серверу БД по локальной сети. Во-вторых отдельный сервер базы данных позволяет масштабировать базу данных отдельно от самого приложения. То есть мы можем мониторить нагрузку этого сервера отдельно, увеличивать его при необходимости или добавлять новый сервер с репликой (копией базы данных), чтобы часть запросов на чтение данных перенести на реплику. NoSQL база данных Для кеша использую БД Redis, который тоже ставлю на отдельный сервер, чтобы к нему могли иметь доступ остальные серверы с приложением. Сессии в идеале тоже нужно хранить на отдельном сервере, чтобы в случае очистки кэша (php artisan cache:clear) они не потерялись - в этом случае пользователям придется заново входить в кабинет (в случае с аутентификацией через сессию). Но я храню сессии вместе с кешем, потому что не уверен, что держать отдельный сервер чисто для сессионных данных оправдано. С задачами для очередей ситуация немного опаснее, потому что если мы храним задачи в той же базе, где кэш, то в случае его очистки мы тупо теряем все задачи, которые были в очереди и НЕ успели обработаться - вот это уже не приятно. Конечно чистить кеш так радикально нельзя, но на практике есть такой кейс. У меня был разный опыт по поводу хранения задач в очереди. Было дело хранил их на worker сервере, где собственно эти задачи и выполняются. Было дело хранил их на сервере кэширования, а когда очистили кэш все задачи пропали. Было дело хранил их на отдельном сервере - это самый спокойный вариант, поэтому сейчас я бы выбрал его. Подводим итог Основную базу данных держим на отдельном сервере, чтобы к нему могли подлючаться все экземпляры приложения, а так же мониторить и обслуживать этот сервер независимо. Обязательно настраиваем резервное копирование базы каждый час. Резервная копия, конечно, должна лежать отдельно (например на другом сервере). Кеш и сессии можно держать вместе, если не очень принципиально потерять сессионный данные в случае очистки кеша, а задачи для очередей держим на отдельном сервере (например worker), потому что их потерять точно не хочется. Дополнительно В последнее время вместо разворачивания серверов с базой (в продакшене) использую облачные базы данных, управляемые поставщиком услуги (Cloud Managed Databases). Там мы просто выбираем тип базы данных (MySQL, PostgreSQL, Redis), размер сервера (процессор, оперативка, размер диска) и всё. База автоматически разворачивается, а наши приложения подключаются к ней, как обычно. Там мы видим основную статистику по работе этой базы, можем увеличивать её мощность, имеем автоматическое резервное копирование (репликацию) и можем добавлять еще экземпляры для чтения в пару кликов. И всё это без остановки приложения! Очень понравилось много лайков в прошлый раз. Ну вы поняли. @onecode_blog 👈

Серверы и масштабирование Бывает такое, что при запуске проекта говорят, что сразу нужно подготовить серверы к нагрузке и масштабирования без остановки приложения. В этом случае я обычно создаю несколько серверов: 1. Балансировщик нагрузки (LoadBalancer). Этот сервер стоит на передовой и принимает все HTTP-запросы к приложению. На сервере стоит веб-сервер Nginx, который проксирует (перенаправляет) запросы к одному из серверов приложений по локальной сети. То есть он скрывает за собой серверы с приложением и распределяет запросы (нагрузку) между ними. На балансировщике стоит SSL-сертификат, таким образом остальные серверы НЕ требуют его установки, тк их общение проходит в локальной (закрытой) сети. 2. Сереры приложения (Application1). Их может быть несколько, но в начале создаю один нужной конфигурации для обработки ожидаемого количества запросов. На этом сервере тоже установлен Nginx, который принимает запросы от балансировщика (первый сервер) и направляет их в приложение - PHP, PHP-FPM, Laravel. 3. Сервер очередей (Queue). Этот сервер НЕ принимает запросы, а занимается только обработкой задач в очереди. На нём так же работают задачи по расписанию, запускаемые ежеминутно через CRON. Тут стоит PHP и тоже самое приложение на Laravel. Очереди всегда работают с помощь Laravel Horizon. 4. WebSocket-сервер (WS). Это опциональный вариант, если для приложения требуется обновление данных на клиенте в реальном времени. Вместо этого сервера можно использовать внешние сервисы, такие как Pusher и Ably (раньше использовал оба). Или развернуть на этом сервере свой вебсокет-сервер на JavaScript, например Soketi (использовал). Или развернуть тоже самое приложение на Laravel с новым пакетом Laravel Reverb (использую сейчас). На этом сервере подключен отдельный домен с SSL для обработки входящих подключений и Nginx, который перенаправляет запросы на сам вебсоке-сервер. Что даёт это разделение? А то, что application серверы скрыты за балансировщиком, позволяет незаметно добавлять новые серверы по мере необходимости. Например нужно увеличить мощность application сервера (вертикальное масштабирование) - тогда просто создаём новый application сервер бОльшей мощности, разворачиваем на нём приложение и говорим балансировщику, чтобы он все запросы отправлял на него, а старый (маленький) application сервер удаляем. Таким образом для увеличения мощности сервера НЕ пришлось останавливать работу сайта. Или другой вариант - просто добавить второй такой же application сервер (горизонтальное масштабирование), балансировщик будет разделять все запросы между двумя серверами и опять же без остановки приложения. Так можно добавлять еще сервера в будущем по мере роста нагрузки. Что касается сервера очередей и вебсокет-сервера, то их в этой схеме не получится увеличить без простоя, то есть пока сервер выключен (увеличивается), задачи в очереди обрабатываться не будут, а когда включится - обработка продолжиться. Обычно это занимает 2 минуты, поэтому для очередей это не так критично, а сам сайт продолжает работу. С вебсокетами аналогично. Не вижу смысла здесь сильно запариваться. Нужно продолжение? С тебя лайк и репост! @onecode_blog 👈

Доброе утро, банда! 🤘🎸

Новая версия поиска от Яндекса, которая по нашему запросу анализирует несколько сайтов и выдаёт ёмкий ответ. При этом можно продолжить диалог, чтобы задать уточняющие вопросы. Прикольно! Заценить: https://ya.ru/?neuro=1

Сегодня в VIP-канале вышел очередной (25й) урок из курса по аутентификации. В уроке для разнообразия использовани Livewire, чтобы реализовать переход по ссылкам и функционал без обновления страницы и без написания кода на JavaScript. Быстро, просто и красиво. Очень нравится Livewire, для ленивых веб-ремесленников самое то 😁

Нарабатываю привычку задавать вопросы ИИ вместо поисковика. Последнее время делаю это каждый день. Не всегда идеально, но прикольно. Возможность обсудить любой вопрос со специалистом по всем вопросам 😁 Недавно надо было сделать быстрый перевод сайта на английский язык. Отправить ИИ файл (json) с текстами на русском, получил в ответ такой же с переводами, вставил в проект и готово 🚀 Так что пользуйтесь тоже, привыкайте, учитесь правильно задавать вопросы и получайте профит. Сегодня наша работа стала такой простой, как никогда, благодаря крутым инструментам 🔥

Конвертер шрифтов Если нужно конвертнуть шрифт во все форматы. На выходе архив со шрифтом в разных форматах и CSS-файл с подлючением. https://transfonter.org/

Джун: я не знаю, как сделать задачу. Миддл: я знаю, как сделать задачу. Синиор: я знаю, как не делать задачу. Хорошей пятницы и выходных! @onecode_blog

В нашем VIP-канале читаем книги - изучаем структуры данных и алгоритмы, принципы работы компьютеров - память, процессор и тд, одним словом компьютерную науку. Мы делаем это через чтение книг - наш книжный клуб, где я выкладываю конспекты прочитанного материала. Очень интересная и полезная история, а канал даёт энергию на это дело, потому что иначе кажется, что нет времени.

ChatGPT без регистрации Компания начала открывать свой бот для пользователей без необходимости регистрации. Однако наличие аккаута даёт больше возможностей, таких как хранение истории чатов и дополнительные функции. https://openai.com/blog/start-using-chatgpt-instantly @onecode_blog

Как получить значения CSS-свойств из JavaScript? Мой кейс: на страницу нужно вывести график (chart.js), при этом в графике нужно использовать фирменные цвета проекта. Но не хранить же цвета в JS, ведь они уже указаны в CSS проекта. Хочу получать их оттуда, чтобы при редактировании цветов в CSS у меня автоматом менялись цвета в графике на JS. Для начала посмотрим на глобальную функцию getComputedStyle, которая позволяет получить значения CSS-свойств любого элемента на странице:

const button = document.querySelector('.btn');
const styles = getComputedStyle(button);
styles.backgroundColor; // #2c7be5
styles.width; // 123px

Таким образом мы можем получить стили любого элемента, но как решить нашу задачу с цветами для графика? Это легко сделать, испольльзуя CSS-переменные, которые вообще давно пора использовать во всех проектах, потому что это офигенная штука. При использовании CSS-переменных, мы объявляем в них глобальные значения, такие как цвета, которые дальше переиспользуем в вёрстке. При этом мы объявляем такие переменные для корневого элемента (html) вот так:

:root {
  --color-primary: #2c7be5;
  --color-success: #00d97e;
  --color-danger: #e63757;
}

После этого можем использовать их при вёрстке:

.btn-primary {
    background-color: var(--color-primary);
}

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

const html = document.documentElement;
const styles = getComputedStyle(html);
styles.getPropertyValue('--color-primary'); // #2c7be5
styles.getPropertyValue('--color-success'); // #00d97e
styles.getPropertyValue('--color-danger'); // #e63757

В итоге мы имеем цвета для нашего графика. Подпишись: @onecode_blog

Попросил ИИ сверстать по картинке. Слева промпт, справа результат. Думаю если его предварительно настроить - сказать, что он крутой верстальщик, использующий TailwindCSS, задать цвета, шрифты и другие вводные, то можно получить лучший результат. Но всё равно прикольно! Подпишись: @onecode_blog

Сегодня выходной, сразу мозг заработал и хочется много всего написать 😆 Добавлю, что регулярно покупаю разные продукты (программы или курсы), оплачиваю ежемесячные подписки, если считаю что это приносит мне пользу. Инвестирую в своё образование или инструментарий. К слову про Калеба (разработчик Livewire и AlpineJS) - пару лет назад покупал у него курс по использованию редактора кода, где он показывал свои настройки и горячие клавиши. Многое взял для себя от него. Потом покупал у него доступ к библиотеке компонентов для AlpineJS. По факту НЕ пользовался, но было интересно посмотреть что там есть и как работает. Сегодня вот оформил подписку на его скринкасты. Так же покупал доступ к библиотеке компонентов TailwindUI, которой время от времени пользуюсь. Так же покупал прикольную тему на бутстрапе, которую тоже использую, если нужно быстро собрать кабинет пользвователя. Можно перечислять и дальше, но факт в том, что благодаря в том числе этим инструментам и инвестициям, сегодня имею тот результат, который имею. Искренне считаю, что чем больше отдаёшь - тем больше получаешь! Возможно прозвучит НЕ приятно, но периодически удивляюсь, как люди сомневаются офрмить подписку на VIP-канал OneCode или нет? Получить мой личный опыт на русском языке с понятными объяснениями, обратной связью и доступом к исходному коду. Че тут думать? Если хочешь быстрее развиваться, перенимать чужой опыт и двигаться вперёд, то конечно ответ ДА - офрмлять. Лично я всегда так делал, делаю и буду делать. Всего 990 рублей в месяц! Мы сегодня только позавтракали в кафе на 5000 рублей 😁 Если у тебя нет 1000 рублей в месяц или тебе нужно всё взвесить, чтобы потратить косарь, то задумайся о своей жизни - как ты до этого докатился? Значит давно пора поднимать задницу и работать еще усерднее в правильном направлении с правильными людьми. Короче, парни, держим фокус на своём развитии и мышлении - это основа всего.

Знаете, мне реально так нравится эта тема, поэтому, чтобы НЕ быть голословным решил поддержать Калеба - разработчик Livewire и AlpineJS. У него есть скринкасты по Livewire за 15$ в месяц. Сами видео уроки мне НЕ нужны, потому что всё уже умею сам, но хочется поддержать человека. Короче оформил подписку с благодарностью за классные инструменты, которые помогают мне в работе. По сути влияют на мою жизнь.

Мне всегда нравился эффект, который даёт SPA. Когда страница НЕ перезагружается в бразуере полностью через редиректы - это даёт намного более приятные ощущения от пользования сайтом. Но сложность, которую вносит отдельный фронтенд, даже на Nuxt, меня останавливает от разработки таких приложений. Потому что это намного больше кода, больше времени на разработку и больше вероятность ошибок. Поэтому лично для меня Livewire офигенный вариант, чтобы выдавать заказчикам быстрый и качественный результат, а самому больше зарабатывать и кайфовать от всех возможностей, которые даёт фреймворк Laravel и его экосистема.

Livewire позволяет сделать навигацию по сайту (переход по ссылкам) БЕЗ перезагрузки страницы. Получается эффект одностраничного приложения (SPA). Нужно просто указать для ссылок атрибут wire:navigate, как на скрине. Накидал небольшой проект и скажу вам - это охрененно! Переходы по страницам работают очень быстро, как будто фронтенд реально написан на Vue или React. При этом НЕ написал ни строчки на JS - просто подключил Livewire и добавил атрибут для ссылок - всё. Лично мне очень заходит эта тема из-за её простоты, удобства и скорости разработки. Оптимальный вариант. https://livewire.laravel.com/docs/navigate Подпишись: @onecode_blog