#system_design 🏗
Продолжаем разбирать архитектуру систем!
❓Что нужно, чтобы горизонтально масштабировать проект? Существует много техник достижения этого. Среди них:
⭐️ шардирование
⭐️ партиционирование
⭐️ репликация.
Сегодня мы поговорим о последней.
❓Итак, что же такое репликация?
C ней как раз все просто - вместо одного экземпляра нашего сервера мы запускаем несколько. Когда единственный экземпляр не справляется с возросшим количеством запросов, ему на помощь приходят другие - с точно таким же серверным приложением и такой же логикой обработки запроса.
Когда в нашем кластере несколько серверов, запросы больше не должны приходить на один-едственный из них. Это нивелировало бы всякую пользу от горизонтального масштабирования. Каждый из серверов в кластере должен получать часть запросов - и, желательно, равномерно. Поделить общую нагрузку в 500 запросов на 10 серверов - и вот уже каждый принимает лишь по 50 запросов. С такой пропускной способностью уже вполне можно работать.
Для того, чтобы определить, куда именно перенаправить запрос, в распределенных системах существует специальный компонент, называемый балансировщиком нагрузки.
⚖️ Его цель проста - обнаружить пользовательский запрос и с помощью определенного алгоритма выбрать реплику, способную наиболее эффективно обработать запрос в данный момент времени. Таким образом, балансировщик становится своего рода связующим звеном между клиентом и сервером - они больше никогда не общаются напрямую. Одно из преимуществ использования балансировщика заключается в том, что клиенту всё равно, кто именно пришлет ему ответ - главное получить его в разумные сроки.
О том, как балансировать нагрузку. мы поговорим в следующем посте. Ставьте🔥 для продолжения!
Продолжаем разбирать архитектуру систем!
❓Что нужно, чтобы горизонтально масштабировать проект? Существует много техник достижения этого. Среди них:
⭐️ шардирование
⭐️ партиционирование
⭐️ репликация.
Сегодня мы поговорим о последней.
❓Итак, что же такое репликация?
C ней как раз все просто - вместо одного экземпляра нашего сервера мы запускаем несколько. Когда единственный экземпляр не справляется с возросшим количеством запросов, ему на помощь приходят другие - с точно таким же серверным приложением и такой же логикой обработки запроса.
Когда в нашем кластере несколько серверов, запросы больше не должны приходить на один-едственный из них. Это нивелировало бы всякую пользу от горизонтального масштабирования. Каждый из серверов в кластере должен получать часть запросов - и, желательно, равномерно. Поделить общую нагрузку в 500 запросов на 10 серверов - и вот уже каждый принимает лишь по 50 запросов. С такой пропускной способностью уже вполне можно работать.
Для того, чтобы определить, куда именно перенаправить запрос, в распределенных системах существует специальный компонент, называемый балансировщиком нагрузки.
⚖️ Его цель проста - обнаружить пользовательский запрос и с помощью определенного алгоритма выбрать реплику, способную наиболее эффективно обработать запрос в данный момент времени. Таким образом, балансировщик становится своего рода связующим звеном между клиентом и сервером - они больше никогда не общаются напрямую. Одно из преимуществ использования балансировщика заключается в том, что клиенту всё равно, кто именно пришлет ему ответ - главное получить его в разумные сроки.
О том, как балансировать нагрузку. мы поговорим в следующем посте. Ставьте
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥23🤡1
#angular #articles
Мы наконец дожили до этого момента. Ангуляр изобрел свой useEffect😭
А если серьезно, с выходом одной из недавних версий во фреймворка появилось два новых хука: afterRender() и afterNextRender(). Их особенность заключается в том, что они исполняются только в браузерной среде, а на сервере не отрабатывают. В отличие от старых хуков жизненного цикла компонентов, типа ngOnInit.
https://medium.com/@pavel.salauyou/explanation-of-afternextrender-and-afterrender-functions-in-angular-254c35f1d0c6
Мы наконец дожили до этого момента. Ангуляр изобрел свой useEffect😭
А если серьезно, с выходом одной из недавних версий во фреймворка появилось два новых хука: afterRender() и afterNextRender(). Их особенность заключается в том, что они исполняются только в браузерной среде, а на сервере не отрабатывают. В отличие от старых хуков жизненного цикла компонентов, типа ngOnInit.
https://medium.com/@pavel.salauyou/explanation-of-afternextrender-and-afterrender-functions-in-angular-254c35f1d0c6
Medium
Explanation of afterNextRender and afterRender functions in Angular
There are cases when you need to manually manipulate the DOM only on the browser side, for example to get coordinates or block sizes. This…
🔥5🤡4
#articles #angular
Про директивы в Ангуляре
МЕГА-мощная статья про крутые и малоивестные фичи директив в Ангуляре. Сам мало что использовал из описанного в статье. На мой взгляд, этим и определяются интересные материалы - позволяющие взглянуть по новому на привычную технологию.
https://www.angularspace.com/mega-article-superpowers-with-directives-and-dependency-injection/
Про директивы в Ангуляре
МЕГА-мощная статья про крутые и малоивестные фичи директив в Ангуляре. Сам мало что использовал из описанного в статье. На мой взгляд, этим и определяются интересные материалы - позволяющие взглянуть по новому на привычную технологию.
https://www.angularspace.com/mega-article-superpowers-with-directives-and-dependency-injection/
Angular Space
[MEGA Article] - Superpowers with Directives and Dependency Injection
Introduction
I have been saying this for a looong while: Directives are the most underutilized part of Angular. They provide a powerful toolset for doing magic in templates, and yet in most projects, it is used in the most common, "attribute directives…
I have been saying this for a looong while: Directives are the most underutilized part of Angular. They provide a powerful toolset for doing magic in templates, and yet in most projects, it is used in the most common, "attribute directives…
🔥9🤡2
Forwarded from NG Stream (Anton Gorelov)
Оператор безопасного присваивания?
Недавно был представлен пропозал для ECMAscript - оператор безопасного присваивания.
Суть его работы в том, что он преобразует полученный результат в кортеж. Например, если функция завершилась успешно, то получаем
При работе на чистом JS, асинхронные функции оборачиваются в блок try/catch. Довольно часто с добавлением нескольких уровней вложенности. Данный оператор призван устранить этот недостаток. Использовать предлагается, примерно, вот так:
Оператор задизайнен для работы с промисами, async/await, с оператором using.
На мой взгляд, у решения есть несколько минусов.
📌 Получаем больше бойлерплейта с if/else для каждого оператора (fetch, parse и тд). При этом конструкция не заставляет обрабатывать исключения. Как и в случае с try/catch, синтаксис не обязывает это делать.
📌 Еще один способ делать одно и тоже, вместо стандартизации одного подхода.
📌 Отсутствие сигнатуры типов. Как обрабатывать ошибки разного типа? В случае интеграции c TS, компилятору не будет понятно, что за тип ошибки возвращается и как ее обрабатывать.
Что же, поглядим, пропозал пока даже не в основном репозитории комитета TC39.
#js
Недавно был представлен пропозал для ECMAscript - оператор безопасного присваивания.
Суть его работы в том, что он преобразует полученный результат в кортеж. Например, если функция завершилась успешно, то получаем
[null, result]. Если с ошибкой, возвращается [error, null]. Немного прослеживается аналогия с Go,Swift, Rust. Предложение вызвало споры о том, насколько это вообще нужно и насколько удобно.При работе на чистом JS, асинхронные функции оборачиваются в блок try/catch. Довольно часто с добавлением нескольких уровней вложенности. Данный оператор призван устранить этот недостаток. Использовать предлагается, примерно, вот так:
const [error, response] ?= await fetch("https://api.example.com/data")const [validationError, data] ?= validator.parse(json);
if (validationError) {
handleValidationError(validationError);
return;
}
return data;
Оператор задизайнен для работы с промисами, async/await, с оператором using.
На мой взгляд, у решения есть несколько минусов.
📌 Получаем больше бойлерплейта с if/else для каждого оператора (fetch, parse и тд). При этом конструкция не заставляет обрабатывать исключения. Как и в случае с try/catch, синтаксис не обязывает это делать.
📌 Еще один способ делать одно и тоже, вместо стандартизации одного подхода.
📌 Отсутствие сигнатуры типов. Как обрабатывать ошибки разного типа? В случае интеграции c TS, компилятору не будет понятно, что за тип ошибки возвращается и как ее обрабатывать.
Что же, поглядим, пропозал пока даже не в основном репозитории комитета TC39.
#js
🔥6❤3👍1
Настя ведет канал по веб-разработке(и не только!) https://t.me/web_and_more
Внутри - регулярная подборка интересных статей и видосов из мира фронтенда!
Совсем недавно она выступала с классным докладом про доступность в вебе. Обычно не люблю эту тему, но доклад получится интересным, открыл для себя много нового.
Подписываемся, ставим лайки😎
Внутри - регулярная подборка интересных статей и видосов из мира фронтенда!
Совсем недавно она выступала с классным докладом про доступность в вебе. Обычно не люблю эту тему, но доклад получится интересным, открыл для себя много нового.
Подписываемся, ставим лайки😎
Telegram
Веб (и не только) заметки
Когда хочется поделиться
❤4🔥3
Начинаем новую познавательную рубрику на канале!
Метрики производительности фронтенда
Существует перечень метрик от Google под названием Core Web Vitals. Они отражают то, насколько ваш фронтенд отвечает современным стандартам скорости, отзывчивости и удобства использования.
По многочисленным исследованиям, каждая дополнительная секунда загрузки вашего продукта на 70% уменьшает конверсию вашего посетителя в покупателя.
Поэтому крайне важно следить за этими метриками.
Померить данные показатели для своего приложения можно в девтулзах Хрома, на вкладке Lighthouse. Он составит подробный отчет и выдаст рекомендации по оптимизации.
Сегодня мы поговорим о той, что предшествует всем остальным.
Встречайте: Time To First Byte! Сокращенно, TTFB!
Этот показатель отвечает за то, насколько быстро сервер ответил на запрос пользователя о загрузке веб-документ и прислал первый байт инфорфмации
Логично подсчитать, что TTFB = dns lookup сервера + время путешествия запроса с клиента на сервер + время обработки запроса сервером + время путешествия запроса с сервера на клиент
Эксперты из Гугла утверждают, что оптимальным значением является 800мс и менее. ВАЖНО! Речь идет не о загрузке ВСЕГО ответа, а лишь о достижении на клиент первой его части
Как же оптимизировать TTFB?
1️⃣ Подберите мощный хостинг с достаточным количеством ресурсов
2️⃣ Используйте стратегии кэширования на клиенте и сервере
3️⃣ Размещайте свой контент поближе к пользователям в географически распределенных CDN
4️⃣ Уменьшайте размер файла, передаваемого с клиента на сервер
Дальше поговорим о FCP. Оставайтесь на связи!
Метрики производительности фронтенда
Существует перечень метрик от Google под названием Core Web Vitals. Они отражают то, насколько ваш фронтенд отвечает современным стандартам скорости, отзывчивости и удобства использования.
По многочисленным исследованиям, каждая дополнительная секунда загрузки вашего продукта на 70% уменьшает конверсию вашего посетителя в покупателя.
Поэтому крайне важно следить за этими метриками.
Померить данные показатели для своего приложения можно в девтулзах Хрома, на вкладке Lighthouse. Он составит подробный отчет и выдаст рекомендации по оптимизации.
Сегодня мы поговорим о той, что предшествует всем остальным.
Встречайте: Time To First Byte! Сокращенно, TTFB!
Этот показатель отвечает за то, насколько быстро сервер ответил на запрос пользователя о загрузке веб-документ и прислал первый байт инфорфмации
Логично подсчитать, что TTFB = dns lookup сервера + время путешествия запроса с клиента на сервер + время обработки запроса сервером + время путешествия запроса с сервера на клиент
Эксперты из Гугла утверждают, что оптимальным значением является 800мс и менее. ВАЖНО! Речь идет не о загрузке ВСЕГО ответа, а лишь о достижении на клиент первой его части
Как же оптимизировать TTFB?
Дальше поговорим о FCP. Оставайтесь на связи!
Please open Telegram to view this post
VIEW IN TELEGRAM
❤9👍5🤡1
Forwarded from Proglib.academy | IT-курсы
🔀 Чем отличаются системный и бизнес-аналитик? Разбираемся на практике
Дискуссии о том, как разделить определения системного и бизнес-аналитика ведутся в сфере непрерывно. Одни уверены, что это профессия «два в одном», другие — не понимают, какой именно аналитик нужен проекту, и главное — зачем. Раскладываем по полочкам в нашей статье.
👉 Ссылка на статью
Дискуссии о том, как разделить определения системного и бизнес-аналитика ведутся в сфере непрерывно. Одни уверены, что это профессия «два в одном», другие — не понимают, какой именно аналитик нужен проекту, и главное — зачем. Раскладываем по полочкам в нашей статье.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3🔥2🤔1
State of CSS 2024
Вышли результаты ежегодного опроса разработчиков о CSS. Из интересного:
1️⃣ Tailwind все ещё на вершине, его используют чаще других CSS-фреймворков. Хотя мне самому его дизайн не нравится
2️⃣ Тестирование доступности все ещё проводит меньше 10% разработчиков. Но довольно большое количество участников отметили, что проводят тестирование стилей на мобильных устройствах.
3️⃣ :has уже использует большое количество людей. Круто, ведь этот псевдо-селектор позволяет по новому смотреть на CSS!
4️⃣ Современные фичи вроде backdrop-filter и prefers-color-scheme все ещё на стадии принятия. Процент использования не больше 20.
5️⃣ Sass на коне, а вот LESS используют заметно меньше
Полное исследование: тык
Вышли результаты ежегодного опроса разработчиков о CSS. Из интересного:
Полное исследование: тык
Please open Telegram to view this post
VIEW IN TELEGRAM
❤6