Node.JS *

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

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

В интернете опять кто-то не прав – во вчерашнем Node Weekly была ссылка на пост в котором автор пытается измерить и сравнить с "аналогами" производительность Stream API в Node.js. Грусть вызывает, то как автор работает со стримами и какие он выводы он пытается на основе этого сделать:

...this worked pretty well on smaller files, but once I got to the biggest file, the same error happened. Although Node.js was streaming the inputs and outputs, it still attempted to hold the whole file in memory while performing the operations

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

Товарищи инженеры, уже четвертый год пошел, как я взялся преподавать в Киевском политехническом институте. За это время у меня накопилось огромное количество примеров кода и материалов, примерно на 90 лекций. Должен сказать, что за весь период своей профессиональной деятельности (а это 24 года почти ежедневного написания кода), я никогда не подымал свой уровень программирования, как за последние годы, работая со студентами. Если раньше мне казалось, что написать кратко, сложно и внушительно — это верх мастерства, то теперь я осознал, что мой код должны понимать студенты после минимальных объяснений, иначе он никуда не годится. Я пришел к выводу, что способность эту можно и нужно распространить не только на обучающий код, но и на весь рабочий код. Более того, обучающий код не должен существенно отличаться от рабочего кода, потому, что мы учим будущих инженеров делать настоящие системы, а не учебные. А после многочисленных просьб, я решил записывать все лекции в виде скринкастов, которые сразу после завершения лекции отправляются на ютюб. За этот учебный год я планирую записать 100 лекций, из которых уже опубликованы 23, готовы материалы еще для 67 лекций и новых 10 лекций еще в процессе подготовки.

В этой статье речь пойдёт о написании и поддержке полезной и актуальной спецификации для REST API-проекта, которая позволит сэкономить много лишнего кода, а также серьёзно улучшить целостность, надежность и прозрачность прокта в целом.

Что такое RESTful API?

Это миф.

Серьёзно, если вы думаете, что в вашем проекте RESTful API, вы почти наверняка ошибаетесь. Идея RESTful — в построении API, который во всём соответствовал бы архитектурным правилам и ограничениям, описанным стилем REST, однако в реальных условиях это оказывается почти невозможно.

Цель данной статьи – показать на примере зачем нужно reactive programming, как оно связано с функциональным программированием, и как с его помощью можно писать декларативный код, который легко адаптировать к новым требованиям. Кроме того, хочется сделать это максимально кратко и просто на примере приближенном к реальному.

Возьмем такую задачу:
Есть некий сервис c REST API и endpointом /people. При POST-запросе на этот endpoint'a создается новая сущность. Написать функцию которая принимает массив объектов вида { name: 'Max' } и создают набор сущностей посредством API(по-английски, это называется batch-операция).

Давайте решим эту задачу в императивном стиле:

const request = require('superagent')

function batchCreate(bodies) {
  const calls = []
  for (let body of bodies) {
    calls.push(
      request
        .post('/people')
        .send(body)
        .then(r => r.status)
    )
  }
  return Promise.all(calls)
}

Давайте, для сравнения, перепишем этот кусочек кода в функциональном стиле. Для простоты, под функциональным стилем мы будем понимать:

1. Применение функциональных примитивов(.map, .filter, .reduce) вместо императивных циклов(for, while)
2. Код организован в "чистые" функции – они зависят только от своих аргументов и не зависят от состояния системы

Этот пост — перевод оригинальной статьи Пейдж Нидринхауз, full-stack software engineer. Ее основная специальность — JavaScript, но Пейдж изучает и другие языки и фреймворки. А полученным опытом делится со своими читателями. К слову, статья будет интересна начинающим разработчикам.

Недавно я столкнулась с задачей, которая меня заинтересовала, — нужно было извлечь определенные данные из огромного объема неструктурированных файлов Федеральной избирательной комиссии США. Я не слишком много работала с raw-данными, поэтому решила принять вызов и взяться за эту задачу. В качестве инструмента для ее решения я выбрала Node.js.

Преамбула

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

GraphQL замечательный инструмент. Думаю, о его преимуществах уже знают и понимают многие. Тем не менее, есть некоторые нюансы, которые следует знать, когда вы строите свои API на основе GraphQL.

Например, GraphQL позволяет возвращать потребителю (пользователю или программе) запросившем данные только ту их часть, в которой этот потребитель заинтересован. Тем не менее, при построении сервера довольно легко совершить оплошность, которая приводит к тому, что внутри сервера (который может быть, в том числе, — распределенным) данные будут курсировать полными "пачками". В первую очередь это связано с тем, что "из коробки" сам GraphQL не предоставляет удобных инструментов для разбора входящего запроса, а те интерфейсы, которые в нем заложены недостаточно документированы.

Доброго времени суток!

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

Копировать и вставлять код это путь на темную сторону, поэтому было принято решение писать не просто js код, а создавать из него npm пакеты чтобы распространять между своими проектами.

Поиск бесплатных, частных npm репозиториев завел в тупик, а использование частных репозиториев на npm требует платы (а это не наш менталитет).

Поскольку в офисе есть сервер, который работает всегда(почти), было решено развернуть локальный npm.

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

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

Здравствуйте, коллеги. Давным-давно на Хабре уже переводилась статья под авторством Джона Резига как раз на эту тему. Прошло уж 10 лет, а тема по-прежнему требует разъяснений. Поэтому предлагаем интересующимся почитать статью Самера Буны, в которой дается не только теоретический обзор таймеров в JavaScript (в контексте Node.js), но и задачи на них.

Вот и отгремел наш INTERCOM’18, c преферансом и бизнес-кейсами. Как обычно, вход на коференцию был платным: желающие могли купить билеты на TimePad по полной цене, либо… получить скидку у консультанта-рептилоида прямо на сайте. В прошлом году это работало как привычный коллбэк: вы оставляете телефон в специальной форме, Павел звонит вам через минуту и задает вопросы; чем больше правильных ответов, тем выше скидка. В этот раз мы решили поменять механику, сделав ее сложнее как технически, так и в плане вопросов. Под катом – кишки Павлика 2.0, с текущей нодой и веб-сокетами, не забудьте надеть спецодежду перед вскрытием.

Привет, Хабр!

Хочу представить вниманию хабровчан генератор статических сайтов с открытым исходным кодом, написанный на Node.JS, в основе которого лежит Webpack.

Проект вдохновлён тем же Jekyll, но в основе своей использует современный технологический стек. Например, предоставляет возможность «горячей подгрузки» (без перезагрузки страницы) изменённых скриптов и стилей.

Всем привет! Я, как программист, всегда ищу пути для улучшения своих навыков. В один пятничный вечер, в мою голову пришла мысль — «А не написать ли мне компилятор?»

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

Этот материал завершает серию переводов руководства по Node.js. Сегодня мы поговорим о модулях os, events и http, обсудим работу с потоками и базами данных, затронем вопрос использования Node.js при разработке приложений и в продакшне.

Некоторое время назад писал сайт с бэкендом на Express/Node.JS. Возникла проблема с минификацией ответов. Нашел много готовых пакетов, но у всех была проблема — не минифицировался html после шаблонов. В итоге принял решение написать свой маленький и родной велосипед — библиотеку web-minify, позволяющую встроить хук перед отправкой клиенту и модифицировать ответ.

Node.js уже сейчас успешно работает в мировом масштабе, об этом свидетельствую развернутые приложения на нем таких компаний как Netflix, Reddit, Walmart и Ebay. Однако, он имеет свой набор проблем при масштабировании; как с точки зрения масштабирования людей, работающих над единой базой кода, так с точки зрения вертикального и горизонтального масштабирования в облаке. К дополнении моему личному опыту масштабирования Node.js при работе в таких компаниях, как Reddit и Netflix, я поговорил с некоторыми экспертами, работающими в Microsoft Azure, и придумал несколько советов для вас по масштабированию Node.js в вашей компании.

Сегодня, в девятой части перевода руководства по Node.js, мы поговорим о работе с файлами. В частности, речь пойдёт о модулях fs и path — о файловых дескрипторах, о путях к файлам, о получении информации о файлах, об их чтении и записи, о работе с директориями.

Node.js — это серверная платформа. Основная задача сервера — как можно быстрее и эффективнее обрабатывать запросы, поступающие от клиентов, в частности — от браузеров. Восьмая часть перевода руководства по Node.js, которую мы публикуем сегодня, посвящена протоколам HTTP и WebSocket.

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

Сегодня, в шестой части перевода руководства по Node.js, мы поговорим о цикле событий, о стеке вызовов, о функции process.nextTick(), о таймерах. Понимание этих и других механизмов Node.js является одной из основ успешной разработки приложений для этой платформы.