Эта статья является продолжением поста «Angular: понятное введение в NGRX»

Пример NGRX

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

План действий:

1. Установка библиотеки
2. Создание структуры папок для хранилища
3. Создание хранилища и начальных значений
4. Создание действий (Actions)
5. Создание редукторов (Reducers)
6. Создание эффектов (Effects)
7. Создание селекторов (Selectors)
8. Конечная настройка
9. Использование хранилища в компонентах

Итак, давайте сделаем это…

Цель этой статьи — дать чистое и ясное представление о ngrx. Для этого я объясню, что нужно знать и понимать о ngrx, а затем мы увидим это в действии с простыми и понятными примерами кода.

Вот список тем, которые мы будем обсуждать в этой статье:

• Что такое ngrx
• Преимущества использования ngrx
• Недостатки использования ngrx
• Когда использовать ngrx
• Действия, Редукторы, Селекторы, Хранилище и Эффекты

Продолжение статьи с примером использования: «Angular: пример использования NGRX».

Всем привет! В современном мире крайне важна возможность масштабировать приложение по щелчку пальцев, ведь нагрузка на приложение может сильно отличаться в разное время. Наплыв клиентов, которые решили воспользоваться вашим сервисом, может принести как большую прибыль так и убытки. Разбиение приложения на отдельные сервисы решает проблемы с масштабированием, всегда можно добавить инстансов нагруженных сервисов. Это несомненно поможет справиться с нагрузкой и сервис не упадет от нахлынувших на него клиентов. Но микросервисы вместе с неоспоримой пользой, вносят и более сложную структуру приложения, а так же запутанность в их взаимосвязях. Что если даже успешно масштабировав свой сервис, проблемы продолжаются? Время ответа растет и ошибок становится все больше? Как понять, где именно проблема? Ведь каждый запрос к API может порождать за собой цепочку вызовов разных микросервисов, получение данных из нескольких БД и сторонних API. Может это проблема с сетью, или API вашего партнера не справляется с нагрузкой, а может это кеш виноват? В этой статье я постараюсь рассказать, как ответить на эти вопросы и быстро найти точку отказа. Добро пожаловать под кат.

Периодически возникает желание положить в базу «неположимое» — например, засунуть очень длинную строку. Нет, записать ее в поле таблицы — для PostgreSQL проблем нет, но вот в индекс…

Проблема в том, что вся строка (ROW) индекса целиком должна полностью умещаться на одной странице данных (8KB), иначе вас ждет примерно такая ошибка:

ERROR: index row size… exceeds maximum… for index ...

То есть даже в простейшем случае индекса из единственной строки — можно наступить на грабли. Как с ними бороться?

Начало

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

Не только древность моей сборки мотивировала на эту статью, но и еще одна причина: мне больно смотреть, когда заходят на онлайн-сервисы для конвертации scss, минификации javascript и других рутинных задач. Самое забавное — когда сделали мелкую правку, снова нужно проходить все круги ада копипаста.

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

И снова я про тестирование и покрытие.

Наверное, вы уже поперхнулись кофе от вопроса "Зачем снимать покрытие с запущенного приложения" — но такая потребность периодически возникает.

Например:

• Узнать покрытие интеграционных тестов без инстурментализации кода, завершения приложения и выгрузки репорта какими-то сторонними средствами;
• Узнать без долгого ковыряния кода, по каким именно модулям приложения прошёл запрос;
• Определить "мёртвый" код, который по факту не используется в приложении;
• Узнать список транзитивных зависимостей, которые используются на определённые запросы.

Интересно? Поехали!

В докладе представлены некоторые подходы, которые позволяют следить за производительностью SQL-запросов, когда их миллионы в сутки, а контролируемых серверов PostgreSQL — сотни.

Какие технические решения позволяют нам эффективно обрабатывать такой объем информации, и как это облегчает жизнь обычного разработчика.


Кому интересен разбор конкретных проблем и разные техники оптимизаций SQL-запросов и решения типовых DBA-задач в PostgreSQL — можно также ознакомиться с серией статей на эту тему.

В этом посте я хотел бы рассказать и показать процесс создания небольшого API с помощью Deno. Deno — новейшая среда для запуска Javascript и Typescript, разработанная создателем Node.js — Райаном Далем.

Кеширование и серверный пререндеринг (SSR)

Приложение на Next.js (React) имеет из коробки серверный пререндеринг страниц. Это очень хорошо для SEO, и для FMP метрики — время от открытия страницы до первого значимого контента.



Казалось бы, фреймворк умеет в SSR из коробки, зачем вообще писать статью? Есть один нюанс, мы рендерим страницу дважды: сначала на сервере, потом на клиенте, и общее время загрузки неизбежно увеличивается.

Веб-скрапинг — это метод сбора данных с веб-сайтов. Этот термин обычно используется в применении к автоматизированному сбору данных. Сегодня мы поговорим о том, как собирать данные с сайтов анонимно. Причина, по которой некто может захотеть анонимности в деле веб-скрапинга, заключается в том, что многие веб-серверы применяют определённые правила к подключениям с IP-адресов, с которых за некий отрезок времени выполнено какое-то количество запросов. Здесь мы будем пользоваться следующими инструментами:

• Puppeteer — для доступа к веб-страницам.
• Cheerio — для парсинга HTML-кода.
• Tor — для выполнения каждого запроса с различного IP-адреса.

Надо отметить, что правовые аспекты веб-скрапинга — вопрос непростой и часто неясный. Поэтому уважайте «Условия использования» тех страниц, данные которых вы собираете. Вот хороший материал на эту тему.

Сегодня из подручных материалов мы соберём в Яндекс.Облаке Telegram-бот с использованием Yandex Cloud Functions (или Яндекс-функции — для краткости) и Yandex Object Storage (или Объектное хранилище — для ясности). Код будет на Node.js. Однако, имеется одно пикантное обстоятельство — некая организация под названием, скажем так, РоссКомЦензур (цензура запрещена статьёй 29 Конституции РФ), не позволяет интернет-провайдерам России передавать запросы в Telegram API по адресу: https://api.telegram.org/ (UPD: В РФ уже снята блокировка Telegram API). Ну мы и не будем — нет так нет. Ведь в нашем саквояже имеются т.н. вебхуки — с их помощью мы не делаем запросы на конкретный адрес, а всего лишь шлём свой запрос в качестве ответа на любой запрос к нам. То есть, как в Одессе — отвечаем вопросом на вопрос. Поэтому Telegram API в нашем коде фигурировать не будет.

Уже давно я заглядывался на фреймворк для тестирования jest, в котором есть огромное количество всяких вкусных фишек, одна из которых — многопоточное выполнение тестов. При условии того, что у меня был проект на 5000 юнит тестов, миграция обещала быть крайне полезной. Далее я расскажу 14 простых шагов, за которых мне удалось мигрировать — пусть и с некоторыми оговорками — и что мы в результате получили. Спойлер — всё получилось очень круто.

Yarn — менеджер пакетов для ноды — выпустили вторую версию. И, похоже, парни серьёзно вознамерились изменить статус-кво в экосистеме ноды, а то и вообще в пакетных менеджерах. Удаляйте все свои картинки про гигабайтные мамки node_modules, убирайте yarn install из скриптов CI, мы начинаем очередную великую JavaScript-смуту. Если вкратце:

• Режим Plug'n'Play стал дефолтным, а node_modules — вторичным, через плагин.
• Сделали плагин и воркфлоу для монореп — может и lerna будет не нужна.
• Встроили свой мини-шелл, чтобы скрипты пакета без этих ваших cross-env в винде запускать.
• Добавили пролог для проверки правил между воркспейсами.
• npx опять же свой запилили.

Если вы не хотите обновлять все ваши проекты, просто запустите yarn policies set-version ^1 (смотри legacy.yarnpkg.com/en/docs/cli/policies) в репозиториях, которые должны остаться на Yarn 1 и закомитьте результат. Тогда Yarn будет использовать локальные бинарники Yarn 1 вместо глобальных так что все в команде будут использовать одну версию!

В случае JavaScript-движка V8 — очень даже. В этой статье я привожу результаты своего маленького исследования эффективности одной из внутренних оптимизаций V8.

Сегодня мы создадим т.н. Яндекс-функцию (официальное название Yandex Cloud Functions), которая вступив в сговор с сервисом почтовых рассылок SendGrid будет слать «мыло» мирно спящим пользователям (шутка — я знаю, что все мы против спама).

А ещё я противник (но без фанатизма) традиционных серверов, и сторонник т.н. serverless (бессерверных) решений, поскольку не люблю (да и толком не умею) администрировать сервера, а ещё больше — платить за то время, когда они не нагружены. Другое дело — функции. Их кто-то обслуживает без меня, а я плачу только за вызовы. В начале октября 2019 г. Яндекс представил свои Yandex Cloud Functions — кажется первый в РФ serverless. И что особо приятно — для навыков Алисы они вообще бесплатны, поэтому с тех пор находятся в поле моего периферийного зрения. Но давайте уже приступим.

Дорогие товарищи инженеры, сообщество Метархия представляет вашему вниманию современный курс по Node.js, который включает глубокий разбор всех возможностей и аспектов платформы. Основной упор делается на то, как создавать надежные высоконагруженные сервера приложений и API без привязки к конкретному фреймворку и даже протоколу, т.е. абстрагировать бизнес-логику в отдельный слой. К лекциям прикреплено множество примеров кода, демонстрирующих гибкую структуру приложений и архитектурные приемы, в том числе работу с СУБД через слой доступа к данным, создание интерактивных приложений на вебсокетах, обеспечение безопасности, Graceful shutdown, межпроцессовое взаимодействие, предотвращение утечек памяти, масштабирование и кластеризацию при помощи процессов и потоков. На текущий момент в курсе 38 лекций (около 35 и ½ часов видео), 37 репозиториев с примерами кода, 4 PDF со слайдами. Перед основной частью курса по Node.js нужно сначала освоить хоть частично курс по асинхронному программированию.

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



В Klarna используют платформу Node.js. Статья, перевод которой мы публикуем сегодня, посвящена тем урокам, которые специалистам компании удалось извлечь из опыта оптимизации производительности своего сервиса.

Если ваши микросервисы уже используют общую базу PostgreSQL для хранения данных, или ей пользуются несколько экземпляров одного сервиса на разных серверах, можно относительно «дешево» получить возможность обмена сообщениями (PubSub) между ними без интеграции в архитектуру Redis, RabbitMQ-кластера или встройки в код приложения другой MQ-системы.

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

Передавать и получать данные мы станем с помощью механизма NOTIFY/LISTEN, а модельную реализацию соберем для Node.js.



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

Каков наилучший способ беспроблемного увеличения параллелизма в Node.js-сервисе, который используется в продакшне? Это — вопрос, на который моей команде понадобилось ответить пару месяцев назад.

У нас запущено 4000 контейнеров Node (или «воркеров»), обеспечивающих работу нашего сервиса интеграции с банками. Сервис изначально был спроектирован так, что каждый воркер был рассчитан на обработку только одного запроса за раз. Это снижало воздействие на систему тех операций, которые могли неожиданно заблокировать цикл событий и позволяло нам игнорировать различия в использовании ресурсов различными подобными операциями. Но, так как наши мощности были ограничены одновременным выполнением лишь 4000 запросов, система не могла достойно масштабироваться. Скорость выдачи ответов на большинство запросов зависела не от мощности оборудования, а от возможностей сети. Поэтому мы могли бы улучшить систему и снизить стоимость её поддержки в том случае, если бы нашли способ надёжной параллельной обработки запросов.



Занявшись исследованием этого вопроса, мы не смогли найти хорошего руководства, в котором речь шла бы о переходе от «отсутствия параллелизма» в сервисе Node.js к «высокому уровню параллелизма». В результате мы разработали собственную стратегию перехода, которая была основана на тщательном планировании, на хороших инструментах, на средствах мониторинга и на здоровой дозе отладки. В итоге нам удалось повысить уровень параллелизма нашей системы в 30 раз. Это эквивалентно снижению затрат на поддержку системы примерно на 300 тысяч долларов в год.

Данный материал посвящён рассказу о том, как мы увеличили производительность и эффективность наших Node.js-воркеров, и о том, что мы узнали, пройдя этот путь.

Доброго времени суток, друзья!

Прежде чем мы начнем, позвольте мне немного рассказать о коде, который я пишу. Почти весь мой код состоит из Javascript, плюс немного HTML и CSS. Я пишу как клиентский, так и серверный JS. Я тестирую свой код. Я создаю и распространяю библиотеки с открытым исходным кодом, которые используются тысячами разработчиков по всему миру. Для фронтенда я использую React, для бэкенда — Express или бессерверные вычисления.

Вот 5 особенностей JS, без которых я не мог бы писать код. В произвольном порядке. Разумеется, «без которых я не мог бы писать код» — это гипербола. Это «фичи», которые мне по-настоящему нравятся и используются мной постоянно.