В прошлой статье я рассказывал про библиотеку компонентов и утилит handy-ones. Я задумал её не только чтобы делиться с сообществом своими наработками на постоянной основе, но главное - чтобы понять, как должен выглядеть, собираться, тестироваться и дистрибутироваться современный JavaScript-проект.
В этой статье я расскажу как создал модуль под Nest.js позволяющий писать классическое RESTFull API со swagger'ом но клиент будет полностью на WebSocket'ах, звучит странно не так ли? Но зато очень быстро и удобно по итогу)
Идея состоит в том, что вы пишите классическое документированное апи, со всеми типами и плюшками.
В прошлых частях цикла мы:
- рассмотрели базовые концепты работы с многопоточностью в JavaScript на примере среды Node.js;
- научились формировать общую очередь и каналы обмена данными и сигналами, чтобы более эффективно управлять загрузкой потоков;
- использовали разделяемую память и Atomics-операции как самое быстрое средство обмена большими блоками данных;
- и создали отдельный поток-координатор, чтобы устранить негативное влияние синхронного кода в основном потоке исполнения на загрузку потоков вспомогательных.
В сегодняшней, заключительной, части я продемонстрирую, как все эти механики вместе позволяют сделать эффективный микросервис, автоматически подстраивающийся под изменения входящей нагрузки.
В данном случае эффективность - это не про максимально возможную скорость обработки каждой отдельной задачи, а про сбалансированное использование аппаратных ресурсов с учетом тех ограничений, на которые мы готовы пойти. Особенно актуально это для различных "облачных" размещений, где оплата идет за фактически потребленные CPU и RAM.
Вдохновившись документацией MDN, которая позиционирует себя как - Resources for Developers, by Developers, я решил сделать серию статей «От новичка, для новичков», где попытаюсь максимально простым языком рассказывать о разных концепциях в программировании, в основном связанных с JavaScript. Я буду стараться избегать технически-сложного контента, или буду максимально его упрощать.
Это первая статья серии, будет посвящена событийно-ориентированной парадигме применительно к Node.js, а также паттерну «EventEmitter».
P.S. Рассчитываю на конструктивную критику читателей! Всегда буду рад обратной связи. Не стесняйтесь указывать на ошибки или хвалить, пишите в комментариях и в личку. Особенно буду благодарен если вы предложите темы для статей!
Если вы делаете финансовый проект или проект в сфере крипты, в котором сохраняются финансовые данные, вам понадобится модуль, который будет отвечать за правильную работу с финансовыми данными.
Правильное решение - это со старта внедрять бухгалтерию с двойной записью (double ledger).
Людям, не знакомым с принципами бухгалтерии, кажется, что бухгалтерия это сложно. На самом деле это не так, и я покажу вам, почему.
Привет, Хабр! Это моя первая публикация и хотелось бы начать с чего-то полезного для сообщества. С места в карьер… Я запилил расширение для VSCode, которое поможет автоматизировать создание файловой структуры компонентов.
В предыдущей части мы научились эффективно передавать данные вспомогательным потокам из основного через разделяемую память, используя Atomics-операции и блокировки.
Но мы рассматривали все-таки идеальную ситуацию, когда основной поток больше ничем не занимался, кроме обмена с "подчиненными" уже заранее готовыми данными. В реальных же приложениях такое встречается достаточно редко - обычно эти самые данные приходится готовить непосредственно перед передачей. И, бывает, в этом участвует существенная доля синхронного кода, что для JavaScript крайне неприятно, но иногда неизбежно - например, при вычислении регулярных выражений.
Давайте оценим, насколько синхронные операции "роняют" производительность нашего тестового приложения. И узнаем, как можно в разы улучшить ее, "скрестив ужа с ежом", используя выделенный поток-координатор из позапрошлой части статьи совместно с разделяемой памятью.
Всем привет. Меня зовут Андрей, я работаю в компании SegmentStream, занимаюсь вопросами архитектуры, инфраструктуры и написанием кода. Сегодня я расскажу как мы адаптировали Cube под наши нужды. В рамках статьи я не буду подробно рассказывать про сам Cube, если вы не знакомы с Cube, то лучше сначала немного почитать про него на официальном сайте cube.dev/docs. Если говорить про SegmentStream, то мы разрабатываем SaaS-платформу для оптимизации рекламных кампаний на основе машинного обучения. Звучит просто, но я рекомендую почитать, там много интересных вещей.
Также, в статье будет достаточное количество кода на TypeScript, который можно при желании не стесняться заимствовать. Я постараюсь оставлять объяснения к нему.
В предыдущей части мы остановились на мысли, что минимизировать простой вспомогательных потоков нашего приложения можно, если заставить их самих получать себе задачи, не дожидаясь, пока их загрузит кто-то другой со стороны.
Но тут возникает две проблемы:
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 и промежуточных билдов! Только хардкор! Что делать? Выход есть.
Цель статьи - поделиться опытом, болью и поныть немного о проблемах. Никоим образом не ставилось целью показать, что именно такой путь правильный.
