Node.JS *

• Часть 1: Nuxt as fullstack server: frontend + backend API Server
• Часть 2: Additional SSR performance with Nuxt fullstack server

Разработчики Nuxt предлагают 3 метода доступа к API:

1. Встроенный в Nuxt сервер Connect и использование serverMiddleware
2. Интегрированные фреймворки (Express, Koa, Hapi и т.д.)
3. Внешние API сервера

Я покажу на простом примере как организовать API сервер с использованием serverMiddleware на том же инстансе Nuxt, который у нас отвечает за frontend.

С головой ушел в коммерческий проект (Легкая Логистика. Планирование автодоставки), поэтому решил раздать исходники хоббийных проектов.

Не так давно, в 2018 году, прогремел хорошо забытый новый вид атак — Zip Slip.

Zip Slip является широко распространенной критической уязвимостью распаковки архивов, позволяющей злоумышленникам записывать произвольные файлы в систему, что обычно приводит к удаленному выполнению команд. Она была обнаружена и раскрыта командой Snyk Security в преддверии публичного разглашения — 5 июня 2018 года и затронула тысячи проектов, в том числе HP, Amazon, Apache, Pivotal и многие другие.

Дополнительную информацию о технических подробностях Zip Slip можно найти на сайте.

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

Но совсем недавно появился новый случай не менее интересный, чем предыдущие.
Zip Slip в популярной библиотеке для Node.js — «decompress».

Введение

В предыдущей статье мы рассмотрели с Вами вопрос интеграции фреймворка «Webix» в «Electron» и создание на основе этих фреймворков простого GUI приложения. Цель данной статьи является дальнейшую развитие вопроса интеграции в GUI интерфейс, построенный с помощью «Electron» и «Webix» других «JavaScript» фреймворков. Все элементы GUI реализованные в «Webix» характеризуются параметром «view». В зависимости от значения этого параметра будет отображаться тот или иной GUI элемент. Количество типов элементов «view», которые позволяет создавать «Webix» перекрывают порядка 90% задач при реализации интерфейса. Оставшиеся 10% это как раз тот случай, когда необходимо осуществить интеграцию либо ранее написанного кода либо фреймворка (библиотеки), которые в явном виде не поддерживаются в «Webix». Для осуществления интеграции со сторонними фреймворками(библиотеки) создадим вместе с Вами свой «view» элемент «Webix».

Постановка задачи

Создать GUI приложение «Electron+Webix», которое будет строить график функции вида «y=a*sin(b)+c» с возможностью изменения параметров функции «a, b и c» с динамической перерисовкой графика.

Введение

Доброе время суток! Хотелось поделиться с Вами личным опытом создания десктопного приложения на JavaScript с использованием связки Electron и Webix. Такая связка позволяет ускорить процесс верстки интерфейса, особо не тратя время на разметку и прочие web штуки, которыми может заняться как раз фреймворк Webix.

Инструменты

Итак приступим, на понадобится следующие инструменты:

1. Редактор, в котором мы будем писать непосредственно наш код. Я буду использовать visual studio code (VSC), который можно взять отсюда ;
2. Сервер Node.js, который можно взять отсюда . Скачиваем его и устанавливаем;
3. Фреймворк «Webix» бесплатную версию (Webix Standard is a free UI library under GNU GPLv3 license), которую берем вот отсюда webix.com/get-webix-gpl. Для того что бы его скачать нужно перейти по выше приведенной ссылке, вести email, имя и фамилию, поставить три галочки нажать отправить после чего Вам на почту отправят ссылку для скачивания.

Привет, Хабр! Предлагаю вашему вниманию перевод статьи Implementing SOLID and the onion architecture in Node.js with TypeScript and InversifyJS автора Remo H. Jansen

В этой статье мы рассмотрим архитектуру, известную как слоистая (onion). Слоистая архитектура — подход к построению архитектуры приложения, придерживающийся принципов SOLID. Он создан под влиянием DDD и некоторых принципов функционального программирования, а также, активно применяет принцип инъекции зависимостей.

Предпосылки

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

Принцип разделения ответственности

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

Прежде чем начну, должен оставить ссылку на предыдущую статью, чтобы было понятно о чем именно речь.

В этой статье хотел бы разобрать слой, который отвечает за хранение файлов, и как это может быть использовано любым человеком. Storacle — самостоятельная библиотека, никакой связи с музыкой напрямую нет. Можно организовать хранение любых файлов.

Что делать, если в базу хочется записать массу «фактов» много большего объема, чем она способна выдержать? Сначала, конечно, приводим данные к более экономичной нормальной форме и получаем «словари», в которые будем писать однократно. Но как это делать наиболее эффективно?

Именно с таким вопросом мы столкнулись при разработке мониторинга и анализа логов серверов PostgreSQL, когда остальные способы оптимизации записи в БД оказались исчерпаны.

Сразу оговоримся, что наши коллекторы работают под управлением Node.js, поэтому с процессорными регистрами и кэшами мы никак не взаимодействуем. А вариант использования «стораджей» или внешних кэширующих сервисов/БД дает слишком большие задержки при входящих потоках в несколько сотен Mbps.

Поэтому мы стараемся кэшировать все в RAM, конкретно — в памяти JavaScript-процесса. Про то, как эффективнее это организовать, и пойдет речь дальше.

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

Веб-сокеты и Socket.IO, вероятно, являются двумя наиболее распространенными средствами коммуникации в режиме реального времени (далее — живое общение). Но чем они отличаются?

При построении приложения для живого общения наступает момент, когда необходимо выбрать средство для обмена данными между клиентом и сервером. Веб-сокеты и Socket.IO являются самыми популярными средствами живого общения в современном вебе. Какое из них выбрать? В чем разница между этими технологиями? Давайте выясним.

Полина Гуртовая — frontend-разработчик уже более 5ти лет, работает в компании Evil Martians. Она не только прекрасный специалист, но и член программного комитета секции Frontend на конференции DUMP 2020, а еще спикер секции этого же года.

Мы пообщались с Полиной и задали ей несколько, как нам показалось, важных вопросов о будущем и настоящем Frontend`а, спросили ее мнение о трендах и тенденциях направления.

Вот что отвечает «злая марсианка» :)

Всем привет!

Относительно давно мне прилетела задача по учебе написание курсовой, и я её наконец-то написал. Чтобы добро не пропадало, я решил оформить её (курсовую) в виде статьи. Надеюсь, статья будет полезна не только для тех, кто хочет погрузиться в мир Web разработки, но и так же для тех, кто считает, что современный веб не так уж и сложен, чтобы платить высокую ЗП.

Итак, тема курсовой:

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

Разработкой всяких SPA и PWA я занимаюсь очень давно, но вот как-то не было случая пощупать Electron. Не спеша закрывая MS Visual Studio, подумал, почему бы нет...

И, пожалуй, начнём с инструментов разработчика.

За последние 5 лет Node.js очень изменился, но знания о платформе у сообщества остались на уровне 2013-2015 годов, все те же подходы, все те же проблемы. Сообщество плохо следит за новыми возможностями, а если и узнает про них, то это не влияет на написание ежедневного кода. В Node.js, да и в JavaScript, слабо проникают фундаментальные знания по программной инженерии и архитектуре, параллельному программированию, GRASP, SOLID, GoF, а если и проникают, то не подвергаются адаптации и переосмыслению. Поэтому, среди других языков программирования JavaScript воспринимается, как несерьезный, а в среде разработчиков Java, C++, C#, распространено мнение, что Node.js, это платформа для малограмотных людей. Как преодолеть эту тенденцию и как изменить подход к разработке на Node.js в 2020 году, с использованием всех современных возможностей и знаний, а так же, что нужно изменить в ежедневных практиках написания кода, эти и другие вопросы рассматриваются в трех бесплатных вебинарах «Node.js в 2020: Выйди и зайди нормально» 11, 14 и 21 апреля, накануне выхода Node.js v14.

Утечки памяти похожи на сущности, паразитирующие на приложении. Они незаметно проникают в системы, поначалу не принося никакого вреда. Но если утечка оказывается достаточно сильной — она способна довести приложение до катастрофы. Например — сильно его замедлить или попросту «убить».



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

Утром, не сделав и глотка кофе, открываешь почту и видишь баг репорты по тому, что вполне себе нормально работало, не сбоило и особо не беспокоило. Идей с ходу ноль, подозреваемых нет, больших изменений в коде тоже не было — нужно лезть в логи.

А туда ты не ходил так давно, что раздало файл с логами аж до 100 мб. или до 500 мб. Черт! А может и до 10 Гб (*). И лежат драгоценные улики где-то там среди 10 737 418 240 байтов, что надо срочно пробежать, дабы выяснить, что ж вообще происходит, меж тем как кофе уже остывает.

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

Знакомо?

В общем все мы так или иначе сталкиваемся с необходимостью анализа «следов жизнедеятельности» наших творений и хорошо если файл весит пару Мб, потому как открыть лог в 1 Гб блокнотом, да ещё и попытаться поиск сделать — занятие весьма сомнительное.

Под катом поведаю об одном инструменте, не имеющим лимитов (**) по размерности открываемых файлов, зато обладающим весьма шустрым поиском.

А ещё приглашу к разработке присоединиться.

И да, будет много интересных картинок.

Кратко об этом модуле

Этот модуль разработан мной для упрощения взаимодействия между Postgres и JS.
Я понимаю что есть много подобных модулей, но хотелось сделать что то гибкое и простое в обращение средство для разных нужд.

Модуль объединяет в себе три важные функции: валидацию входных данных, постройку запросов в базу данных и вывод данных в JSON.

Собрался я однажды написать приложение, чтобы отбирать музыку для себя и слушать дома/на улице/тренировках и.т.д. И чтобы все это работало в потоке, с минимальным моим участием. Придумал архитектуру, набросал прототип и в итоге столкнулся с одной “небольшой проблемой”.

Falcon Heavy Demo Mission

Писать тесты скучно. А то, что скучно делать, постоянно откладывается. Меня зовут Назим Гафаров, я разработчик интерфейсов в Mail.ru Cloud Solutions, и в этой статье покажу вам другой, немного странный подход к автоматизированному тестированию.

Бэкдор в собственном коде, который может незаметно взаимодействовать с операционной системой, это один из самых страшных кошмаров любого разработчика. В настоящий момент в npm имеется более 1.2 миллиона общедоступных пакетов. За последние три года зависимости проектов превратились в идеальную цель для киберпреступников. Экосистема npm может оказаться на удивление хрупкой в том случае, если сообщество разработчиков не обратит пристальное внимание на безопасность. В качестве доказательств этой мысли достаточно вспомнить о тайпсквоттинге и об инциденте с npm-пакетом event-stream.



Автор статьи, перевод которой мы сегодня публикуем, хочет, в образовательных целях, рассказать о том, как создавать бэкдоры для платформы Node.js.

Встретились как-то три разработчика на перепутье JavaScript фреймворков. Смотрят — валун лежит, а на нем указатели: налево — React.js, направо — Node.js, прямо пойдешь — Fullstack JS станешь. Начали разработчики спорить, какой путь выбрать, и у каждого своя правда была… Сегодня вы услышите сказ о трех разных курсах по JavaScript и, быть может, узнаете себя в одном из наших героев.

---

Первого разработчика звали Илья. Был он опытным фронтендером, но хотел и не только на фронте, но и дома быть полезным, чтоб с простыми задачами самому справляться — там серверок настроить, тут API прикрутить. Второй, Добрыня, был профи в бэкенде — что угодно мог построить-собрать! Команда души в нем не чаяла, но нет-нет, да хотелось ему какого-нибудь подвига заметного, осязаемого: хоть кнопку какую сделать или форму интерактивную людям в пользование. Третий, Алеша, только недавно начал свой путь в разработке, но сразу загорелся стать мастером на все руки: чтоб, как говорится, и в фронт, и в бэк, и в добрые юзеры.

Всем привет! Совсем скоро стартует курс «Разработчик Node.js», в связи с чем мы провели традиционный открытый урок. На вебинаре рассмотрели сильные и слабые стороны Node, а также обсудили, для каких задач эта программная платформа подходит лучше всего, а для каких следует выбирать другие языки и фреймворки. И, разумеется, не обошлось без практики. Для запуска примеров и программ необходимо было установить Node.js.

Преподаватель — Александр Коржиков, Dev IT Engineer в компании ING Group (Нидерланды).

---