Node.JS *

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

Но тут возникает две проблемы:

1. как эффективно доставить данные в обрабатывающий поток

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

В этом нам как раз и помогут два рассматриваемых в этой статье концепта работы с многопоточностью: разделяемая (shared) память и потокобезопасные (thread-safe, Atomics) операции над ней.

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

Если посмотреть на результаты The State of JS 2021 в разделе «Библиотеки — Бэкенд-фреймворки», то минимум 5 из них (возможно, больше) будут как раз FullStack. Отсортировав бэкенд-фреймворки по заинтересованности, в самом верху списка мы снова увидим именно FullStack. Это понятно — они востребованы и лежат в основе разных проектов.

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

В первой части статьи мы остановились на моменте, когда с помощью распределения задач между потоками по алгоритму Round-robin мы добились-таки ускорения работы приложения за счет многопоточности.

Но вот неприятность: такой алгоритм очень неравномерно нагружает потоки и не полностью утилизирует их возможности - пока кто-то простаивает, другой уже копит очередь. Как это можно обойти?

Совсем недавно начал изучать фреймворк Fastify, который почему-то не особо популярен в русскоязычном сегменте интернета. Для хранения переменных конфигурации я всегда использовал файл .env. Для чтения файла .env на Express я привык использовать всем известную библиотеку dotenv, то врем как в экосистеме Fastify есть своя библиотека - @fastify-env.

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

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

Итак, ниже пойдёт перевод этой статьи от 27.07.2021 г. (обновлено 18.02.2022 г.). Перед прочтением статьи рекомендую потратить 5-10 минут времени на чтение ооочень короткой официальной документации библиотеки @fastify-env.

Продолжаем серию статей, посвященных разным прикладным концептуальным решениям, которые могут существенно "прокачать" производительность вашего Node.js-приложения.

В прошлой статье мы рассмотрели реализацию эффективной очереди на основе "эластичного" кольцевого буфера, а в этой попробуем разобраться с особенностями использования модуля Worker threads в Node.js - какие проблемы внедрения многопоточности будут нас ждать при попытках сделать код более производительным, и узнаем, как их можно обойти, применяя типовые концепты.

Начнем с достаточно типовой задачи: мы получаем некоторые сообщения, и нам их надо как-то обработать. В качестве тестового примера сгенерируем эти сообщения самостоятельно, и посмотрим, за какое минимальное время мы сможем вычислить SHA-256-хэш для каждого из них.

"По классике" FIFO-очередь для обработки некоторого потока задач обычно реализуется в виде связанного списка элементов. Но для JavaScript такой подход нехорош - он требует либо создания "обвязки" над элементом очереди в виде дополнительного объекта, содержащего ссылки на сам элемент и указатель на следующий, либо превращения элемента в объект и расширения его таким же указателем.

В таких нагруженных системах, как коллектор нашего сервиса мониторинга PostgreSQL-серверов, создание и последующая подчистка Garbage Collector'ом подобных избыточных объектов и полей - непозволительная роскошь.

Но если внимательно посмотреть на эту схему, то можно заметить, что сами элементы очереди A, B, C линейно упорядочены. Так нельзя ли использовать в качестве очереди обычный массив с его .push() и .shift()?..

Насколько это будет эффективно, какие грабли встретятся на этом пути, и как их можно обойти - сегодня об этом.

Всем привет! Меня зовут Николай Каменев, я фронтенд-разработчик в Почтатехе. Мы разрабатываем UI для порталов и приложений Почты России.

Я хочу поделиться коротким гайдом, как автоматически рендерить og:image-изображения для превью сайтов.

Друзья, всем привет! Меня зовут Игорь Карелин, я frontend-разработчик в компании Домклик. В прошлой части мы разобрались, как настроить и запустить проект, а сегодня продолжим создавать наш планировщик и поэтапно разберём создание аутентификации с помощью библиотеки Passport.

Доброго дня, хабровчане!

Как и обещал, в продолжение своего пет-проекта по созданию грид-компонента опишу здесь создание backend части.

Итак, работая над... ну не знаю... каким-нибудь замечательным генератором статики, вы, возможно, захотите импортировать в свой код зависимости напрямую из текстовых файлов, таких как: HTML, MD, CSS, SVG или JSON. Конечно, можно использовать бандлер с соответствующим лоадером. Но, допустим, ваш кодекс самурая велит вам - никаких лишних npm install xxx и промежуточных билдов! Только хардкор! Что делать? Выход есть.

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

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

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

На самом деле есть другое решение.

Привет, друзья!

В данном туториале мы разработаем чат с использованием следующих технологий:

• TypeScript — статический типизатор;
• NestJS — сервер;
• Socket.IO — библиотека для работы в веб-сокетами;
• React — клиент;
• TailwindCSS — библиотека для стилизации;
• PostgreSQL — база данных (далее — БД);
• Prisma — ORM;
• Docker — платформа для разработки, доставки и запуска приложений в изолированной среде — контейнере.

Функционал чата будет таким:

• фейковая регистрация пользователей:
  
  • хранение имен пользователей в памяти (объекте) на сервере;
  • хранение имен и идентификаторов пользователей в localStorage на клиенте;
• регистрация подключений и отключений пользователей на сервере и передача этой информации подключенным клиентам;
• запись, обновление и удаление сообщений из БД в реальном времени на сервере и передача этой информации клиентам.

Репозиторий с кодом проекта.

Если вам это интересно, прошу под кат.

В этой статье поговорим о том, как написать в React многократно используемый код, используя три шаблона проектирования группы Gang-of-Four.

В этой статье поговорим о том, как разработать и запустить бэкэнд на Node.js-Express и фронтенд на React в контейнере Docker.

NestJS прекрасный фреймворк под Node.js, вдохновлённый серьёзными фреймворками Spring, ASP.NET Core, Simfony.

Так что же там внутри прекрасного и ужасного?

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

Привет, друзья!

Представляю вашему вниманию перевод этой замечательной статьи.

Данная статья включает в себя:

• обзор основных частей интерфейса Node.js для работы с файловой системой (далее — ФС);
• рецепты (сниппеты кода) для выполнения задач с помощью названного интерфейса.

Если вам это интересно, прошу под кат.

Привет, друзья!

Представляю вашему вниманию перевод второй части этой замечательной статьи.

Ссылка на первую часть.

Веб-потоки (web streams) — это стандарт для потоков (streams), который поддерживается всеми основными веб-платформами: веб-браузерами, Node.js и Deno. Потоки — это абстракция для чтения и записи данных последовательно, небольшими частями из любого вида источника — файлов, данных, находящихся на сервере, и т.д.

Например, глобальная функция fetch (которая используется для загрузки онлайн-ресурсов) асинхронно возвращает ответ (Response), содержащий свойство body с веб-потоком.

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

Привет, друзья!

Представляю вашему вниманию перевод первой части этой замечательной статьи.

Ссылка на вторую часть.

Веб-потоки (web streams) — это стандарт для потоков (streams), который поддерживается всеми основными веб-платформами: веб-браузерами, Node.js и Deno. Потоки — это абстракция для чтения и записи данных последовательно, небольшими частями из любого вида источника — файлов, данных, находящихся на сервере, и т.д.

Например, глобальная функция fetch (которая используется для загрузки онлайн-ресурсов) асинхронно возвращает ответ (Response), содержащий свойство body с веб-потоком.

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