Forwarded from 🦊 Angular Fox 🚀 — русскогорящие новости сообщества
✨ Angular Platforms: как запускать приложение где угодно?
Angular — мощная технология для разработки фронтенда. Но ограничивается ли она только вебом?
Олег Соловьев рассмотрел встроенные платформы и способы запуска Angular-приложений в самых неожиданных местах, даже в терминале.
👉 https://www.youtube.com/watch?v=1ODglCYgzwc
Angular — мощная технология для разработки фронтенда. Но ограничивается ли она только вебом?
Олег Соловьев рассмотрел встроенные платформы и способы запуска Angular-приложений в самых неожиданных местах, даже в терминале.
👉 https://www.youtube.com/watch?v=1ODglCYgzwc
🔥14
#system_design 🏗
Продолжаем разбирать архитектуру систем!
Сегодня поговорим о ГОРИЗОНТАЛЬНОМ МАСШТАБИРОВАНИИ
В прошлом посте мы выяснили ограничение, в которое упирается вертикальное масштабирование. Чем же отличается горизонтальное?
Для начала давайте поймем, что это вообще такое.
↔️ При горизонтальном масштабировании вместо наращивания мощности одной машины мы поднимаем ещё один сервер, создаем несколько новых инстансов базы данных - таким образом, создаем кластер. Теперь наша система состоит из множества машин, взаимодействующих между собой.
Почему это хорошо?
🟢 Низкая стоимость - в долгосрочной перспективе установить в систему новый сервер гораздо дешевле, чем апгрейдить одну-единственную убер-машину
🟢 Эффективное снижение нагрузки - теперь мы можем обрабатывать в тысячи раз больше запросов пользователей, при правильном проектировании каждый сервер будет получать лишь часть запросов
🟢 Масштабируемость - сложно бесконечно наращивать мощности одной машины, но подключать парочку вспомогательных серверов по мере роста нагрузки гораздо проще
🟢 Отказоустойчивость - теперь мы не имеем единой точки отказа. Если одна машина вышла из строя, у нас всегда есть ещё!
🧐 Звучит как идеальное решение, неужели нет минусов?
Разумеется, за такие плюшки приходится платить. Почти все минусы горизонтального масштабирования вытекают из его определения - теперь у нас несколько экземпляров системы вместо одной. Это рождает множество вопросов:
❔ Как синхронизировать данные между экземплярами?
❔ Как понять, какой экземпляр БД какие данные хранит? А какой сервер должен обработать запрос пользователя?
❔ Что делать, если один из экземпляров вышел из строя?
Для решения всех этих проблем нам предстоит погрузиться в устройство распределенных систем и изучить такие важные концепции, как репликация и сегментирование.
Ставьте огонь, если было интересно и хотите продолжение🔥 🔥 🔥
Продолжаем разбирать архитектуру систем!
Сегодня поговорим о ГОРИЗОНТАЛЬНОМ МАСШТАБИРОВАНИИ
В прошлом посте мы выяснили ограничение, в которое упирается вертикальное масштабирование. Чем же отличается горизонтальное?
Для начала давайте поймем, что это вообще такое.
↔️ При горизонтальном масштабировании вместо наращивания мощности одной машины мы поднимаем ещё один сервер, создаем несколько новых инстансов базы данных - таким образом, создаем кластер. Теперь наша система состоит из множества машин, взаимодействующих между собой.
Почему это хорошо?
🟢 Низкая стоимость - в долгосрочной перспективе установить в систему новый сервер гораздо дешевле, чем апгрейдить одну-единственную убер-машину
🟢 Эффективное снижение нагрузки - теперь мы можем обрабатывать в тысячи раз больше запросов пользователей, при правильном проектировании каждый сервер будет получать лишь часть запросов
🟢 Масштабируемость - сложно бесконечно наращивать мощности одной машины, но подключать парочку вспомогательных серверов по мере роста нагрузки гораздо проще
🟢 Отказоустойчивость - теперь мы не имеем единой точки отказа. Если одна машина вышла из строя, у нас всегда есть ещё!
🧐 Звучит как идеальное решение, неужели нет минусов?
Разумеется, за такие плюшки приходится платить. Почти все минусы горизонтального масштабирования вытекают из его определения - теперь у нас несколько экземпляров системы вместо одной. Это рождает множество вопросов:
Для решения всех этих проблем нам предстоит погрузиться в устройство распределенных систем и изучить такие важные концепции, как репликация и сегментирование.
Ставьте огонь, если было интересно и хотите продолжение
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥16🤡3
#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