Node.JS *

Как войти в нужную дверь: API-ключ и как с ним работать

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

Чтобы использовать API-ключ, нужно:

1. Получить его в личном кабинете сервиса.

2. Добавить в запрос — обычно в заголовке Authorization.

3. Следить за безопасностью: не хранить ключ в коде и регулярно менять.

Пример запроса в Node.js:

const axios = require('axios');

const API_KEY = process.env.MY_API_KEY;

axios.get('https://api.example.com/data', {

  headers: { 'Authorization': Api-Key ${API_KEY} }

})

.then(r => console.log(r.data))

.catch(e => console.error('Ошибка', e.response?.status));

В базе знаний Рег.облака поделились подробной инструкцией: как создать, подключить и защитить API-ключ. Заходите, сохраняйте и используйте :) 

Поиск скомпрометированных зависимостей через Dependency Track

На днях стало известно о компрометации почти 2-х десятков npm-пакетов (подробнее в этой статье). Зловредный код может похищать криптовалюту. Это не первый раз, когда в зависимости попадает зловред (например, в 2022 году зловред удалял данные).

Один из вариантов поиска наличия скомпрометированных пакетов среди сотен проектов - использование Dependency Track. При этом поиск возможен и в транзитивных зависимостях тоже. На картинке ниже показан процесс. Заходим в раздел "Components", вводим название в формате "pkg:npm/$name$". Далее остаётся отсортировать по версии и найти среди них скомпрометированную (сейчас это легко - нужно смотреть самую старшую версию). Можно поиск производить сразу по конкретной версии. Пример:

pkg:npm/simple-swizzle@0.2.3

Если пакет нашёлся - можно не только узнать в каком именно проекте, но и увидеть где именно в дереве зависимостей проекта используется (нажать на иконку, обведённую красным).

Если знаете альтернативные варианты поиска скомпрометированных пакетов другими средствами - напишите в комментариях.

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

баг, который 'уже почти пофиксили' никуда из прода не девался
фича, которую 'вот-вот запустим' — всё ещё в черновиках
команда уже тихо ненавидит слово 'архитектура'

А техлид? Техлид как будто ничего не замечает.
Как это работает (точнее, не работает)
Слова вместо кода

вместо пулл-реквестов - диаграммы.
демо нет - зато вот вам слайды.
вместо решений 'опять' 'давайте обсудим' (читай: 'я не хочу отвечать').

Бесконечный 'анализ'

'Надо подумать над архитектурой' = 'Я не уверен, но боюсь признаться'
'Это нетривиальная задача' = 'Мне лень разбираться'

Ответственность - это не про нас
Любимый приём - щедро размазать вину:

'Это комплексная проблема' (на самом деле: 'виноваты все, а значит — никто').

Реальный кейс (чтобы было не абстрактно)

В одном проекте (Node.js, если важно) техлид 2 месяца 'прорабатывал подход' к рефакторингу.
Провёл 8 митингов, написал 50 страниц документации.

А потом... уволился.

Оставив после себя:
красивые схемы в Confluence
ни одной строчки кода
команду, которая теперь на рефакторинг смотреть не может

Как понять, что ваш техлид центральная часть системы самообмана?

главный результат его работы - не код, а презентации
коронный вопрос - 'А как мы это будем масштабировать?' (но не сам масштабирует)
после разговора с ним хочется или закодить, или закопать

Что прикажете с этим делать?

тупо запретить 'стратегировать' без кода*
нет пулл-реквеста - нет права говорить про архитектуру.

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

Задавать всего один вопрос

'Что конкретно изменится после твоего решения?'
Если ответ начинается со слов 'теоретически....' - это тревога.

Вывод
Хороший техлид — не тот, кто красиво говорит о проблемах.
А тот, кто их решает.

Если ваш 'архитектор' только генерирует документы, но не генерирует код - возможно, он уже ИИ.

P.S. Если после этого текста кто-то узнал своего техлида - это не совпадение

Расширенные алерты в Amvera Cloud

Сегодня мы выпускаем функционал расширенных алертов.

Теперь каждый наш пользователь сможет получать уведомления в специальный бот, если:

1. Проект ушел в ошибку.

2. Произошло превышение ОЗУ или ЦПУ выше заданного порога

3. Сработала Liveness или Readiness проба.

4. Произошла ошибка сборки или запуска проекта.

5. Встретилась заданная фраза в логе.

Amvera Cloud — это облако для простого деплоя приложений через git push. Встроенный CI/CD, бэкапы и мониторинг позволяют развернуть проект тремя командами в IDE и не думать о настойке инфраструктуры. Amvera проще, чем использование VPS или Kubernetes-кластера.

RabbitMQ и Memcached в Amvera Cloud

C 14 января 2025 в Amvera Cloud доступны RabbitMQ и Memcached.

Для создания достаточно выбрать необходимый сервис в разделе «Преднастроенные сервисы» и заполнить название и несколько переменных.

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

Amvera Cloud — это облако для простого деплоя приложений через git push. Встроенный CI/CD, бэкапы и мониторинг позволяют развернуть проект тремя командами в IDE и не думать о настойке инфраструктуры. Amvera проще, чем использование VPS или Kubernetes-кластера.

Обновления января 2025 года в Amvera Cloud

Многие ждали, писали, но нет, мы цены повышать не будем!)

Зато сразу после 1 января праздников, ориентировочно 13—17 января

1. Выкатим новый фронт. Надеемся, все станет понятнее.

2. Появятся преднастроенные RabbitMQ и Memcached.

3. Расширенные алерты и пробы. Можно будет настроить алерты на падение проекта, превышение заданного потребления ОЗУ и CPU и появления определенных ошибок в логах. Дополнительно появятся liveness и readiness пробы.

4. Мы вводим SLA. Осенью 2024 были инциденты с падением сервисов. Мы готовы нести ответственность за безотказность работы сервиса. Начиная с января 2025, если наша надежность окажется ниже 99,5% в месяц, можно будет претендовать на компенсации с нашей стороны.

SLA действует с 1 января 2025

Amvera Cloud — это облако для простого деплоя приложений через git push. Встроенный CI/CD, бэкапы и мониторинг позволяют развернуть проект тремя командами в IDE и не думать о настойке инфраструктуры. Amvera проще, чем использование VPS или Kubernetes-кластера.

Запускаем бесплатную программу обучения по Node js в Web3

Привет всем! Мы в MetaLamp давно занимаемся обучение разработчиков, у нас есть свои программы обучения по фронтенду и бэкенду, а недавно мы запустили обучения по смарт-контрактам Solidity и фронтенду в web3.

Теперь мы решили расширить список наших курсов и создали программу обучения по Node.js в связке с web3.

Почему все говорят про Node.js

Node.js уже давно стал одним из главных инструментов для разработки серверной части. Его используют, чтобы строить быстрые и масштабируемые веб-приложения и не только. К примеру, Netflix, LinkedIn и Uber сделали Node.js значимой частью своей инфраструктуры. Так что эта платформа не просто тренд, а эффективный инструмент.

Кроме того, JavaScript (js), на котором базируется Node.js, занимает лидирующие позиции среди языков программирования. И это легко объяснить. Он универсален, используется как на фронтенде, так и на бэкенде, и у него огромное сообщество. Node.js уверенно стоит на первом месте среди серверных технологий. Освоивший ноду, во-первых, станет специалистом по серверным технологиям. Во-вторых, сможет легко изучить фронтенд и перейти в лигу fullstack.

И еще одна приятная деталь: зарплаты в этой сфере радуют. По данным Хабр Карьера, джуниоры на Node получают около 85 тысяч рублей, мидлы — 220 тысяч, а сеньоры могут зарабатывать до 330 тысяч рублей в месяц.

Читайте подробнее о программе в нашей новой статье!

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

Копаем вглубь Dependency Injection (NestJS): запись внутреннего митапа

В Сравни мы используем NestJS, широко применимый фреймворк для Node.js-разработки, который из коробки умеет в Dependency Injection.

Ранее на внутреннем митапе разобрали основы внедрения зависимостей (ссылка ниже) — теперь же рассмотрели динамическое создание и удаление модулей.

В частности:

• Правила: что от чего не должно зависеть

• Какие ставить для себя ограничения

• Как хранить сервисы на нужных уровнях/слоях

• Как избежать циклической зависимости

• forRoot/forChild

• Возможно ли сделать hot module replacement в работающем сервисе

Посмотреть запись митапа можно здесь:

✅YouTube

✅RUTUBE

✅VK

Запись нашего первого митапа по DI доступна в этом плейлисте.

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

Поддержка TypeScript включается при помощи опции "--experimental-strip-types" и сводится к очистке специфичных для данного языка определений типов, то есть преобразованию перед выполнением исходного кода в JavaScript.

Не связанные с описанием типов возможности TypeScript пространства имён, декораторы, свойства параметров и перечисляемые типы (enum) пока не поддерживаются. Протестировать новую опцию можно в ночных сборках Node.js 23.

Для трансляции задействован компилятор SWC (Speedy Web Compiler), написанный на языке Rust. Чтобы не добавлять дополнительные зависимости к Node.js, задействовано представление компилятора swc/wasm-typescript в промежуточном коде WebAssembly и уже применяемое для тех же целей в платформе Deno.

Это изменение добавлено в ответ на просьбы пользователей реализовать возможность запуска кода на TypeScript без установки внешних загрузчиков и дополнительных зависимостей. В проектах Deno и Bun поддержка TypeScript реализована изначально.

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

В добавленной в Node.js реализации данные возможности TypeScript теряются, в процессе трансляции исходных текстов в JavaScript проверка типов не осуществляется.

Источник: OpenNET.

Команда Honeypot выпустила документальный фильм об истории Node.js. В часовом видео подробно рассказали о том, как создавали популярную среду выполнения кода на JavaScript. Фильм продолжает серию, в которой уже есть следующие документальные картины: 

• Ruby on Rails;

• React;

• Prometheus;

• Vue.js;

• GraphQL;

• Ember.js;

Elixir.

OpenAI блокирует доступ к своим продуктам на территории РФ. В какой-то момент стало невозможным открыть даже документацию.

Доступ через VPN пока работает, но мы с друзьями подумали, что это неудобно, и опубликовали документацию OpenAI у себя:

https://openai-docs.ru

Более того, с помощью GPT-4 мы перевели содержание на русский язык и где возможно, заменили ссылки на дополнительные статьи (Wikipedia и подобные) на русскоязычные версии. За бесплатный доступ к GPT-4 для нашего проекта благодарим  ProxyAPI — доступ к OpenAI API в России. 

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

Вышли корректирующие выпуски JavaScript-платформы Node.js 21.6.2, 20.11.1, 18.19.1, в которых исправлено 8 уязвимостей (4 из них с высоким уровнем опасности):

• CVE-2024-21892 — возможность подстановки непривилегированным пользователем кода, наследующего расширенные привилегии, с которыми выполняется рабочий процесс;

• CVE-2024-22019  — отказ в обслуживании через исчерпание доступных ресурсов (нагрузка на CPU и расходование пропускной способности) при обработке встроенным HTTP-сервером специально оформленных chunked-запросов;

• CVE-2024-21896 — выход за границу базового каталога в файловых путях, уязвимость позволяет обойти нормализации файловых путей при помощи path.resolve() в случае передачи пути с использованием класса Buffer;

• CVE-2024-22017 — вызов setuid() не сбрасывал все привилегии;

• CVE-2023-46809 — уязвимость в API privateDecrypt(), допускающая применение атаки Marvin для расшифровки RSA на основе измерения времени операций;

• CVE-2024–21 891 — возможность обхода модели прав доступа при использовании пользовательских обработчиков нормализации файловых путей;

• CVE-2024-21890 — некорректная обработка масок в параметрах "--allow-fs-read" и "--allow-fs-write";

• CVE-2024-22025 — отказ в обслуживании через израсходование ресурсов при декодировании сжатых данных в формате Brotli, полученных через вызов fetch().

Источник: OpenNET.