Node.JS *

Из комментариев к статье стало понятно, что очень многие люди склоняются в сторону экосистемы Create React App (он же React Scripts). Это вполне разумно, т.к. это самый популярный и простой в использовании продукт (благодаря отсутствию конфигурации и поддержке ведущих людей React-сообщества), в котором, к тому же, есть почти все необходимое — сборка, режим разработки, тесты, статистика покрытия. Не хватает только серверного рендеринга.

В качестве одного из способов в официальной документации предлагается либо вбивать начальные данные в шаблон либо воспользоваться статическими слепками. Первый подход не позволит поисковикам нормально индексировать статичный HTML, а второй — не поддерживает проброс никаких начальных данных, кроме HTML (фраза из документации: this doesn't pass down any state except what's contained in the markup). Поэтому если используется Redux, то придется для рендеринга использовать что-то другое.

Я адаптировал пример из статьи для использования с Create React App, теперь он называется Create React Server и умеет запускать серверный рендеринг командой:

create-react-server --createRoutes src/routes.js --createStore src/store.js

В этом небольшом посте я хочу рассказать об одном интересном предложении (англ. proposal) в стандарт EcmaScript. Речь пойдёт об асинхронных итераторах, о том, что это такое, как ими пользоваться и зачем они вообще нужны простому разработчику.

Асинхронные итераторы, это расширение возможностей обычных итераторов, которые с помощью цикла for-of/for-await-of позволяют пробежать по всем элементам коллекции.

Каждый раз начиная писать React приложение, вы так или иначе выберите какой-то вариант:

• копи-паст вашего предыдущего проекта
• какой-то бойлерплейт или даже генератор (типа Yeoman)
• готовый фреймворк не требующий конфигурации
• пишете сами все с нуля

Каждый из способов имеет свои сильные и слабые стороны, как на длинной, так и на короткой дистанции.

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

Это вторая статья о Server Side Rendering и изоморфных/универсальных приложениях на React. Первая под названием "Упрощаем универсальное/изоморфное приложение на React + Router + Redux + Express" была больше про кастомное решение, эта же статья нацелена больше на тех, кому не хочется заморачиваться, а хочется готовое решение, с коммьюнити, и вообще поменьше головной боли с настройкой, отладкой, подбором библиотек и т.д.

+

В данной статье будем рассматривать Next.JS, который обладает преимуществами в виде отсутствия конфигурации, серверного рендеринга и готовой экосистемы.

Из коробки Next.JS не умеет работать с Redux, поэтому в процессе написания пробного проекта я выделил получившийся общий код в отдельный репозиторий next-redux-wrapper, с помощью которого в этой статье мы и соберем приложение-пример на Next.JS + Redux.

Привет! Меня зовут Артем, и я занимаюсь тестированием веб-приложений в Badoo. Я регулярно изучаю профили крупных компаний на Github для того, чтобы узнать что-то новое как в веб-разработке, так и в трендах (иногда в будущих трендах). И это перевод статьи о Neutrino от Mozilla.

Neutrino — это инструмент, объединяющий в себе лучшие компоненты набора современных JavaScript-инструментов и простоту отсутствия первоначальных настроек.

На Хабре уже было предостаточно статей про то, как делать универсальное (изоморфное) приложение на стеке React + Redux + Router + Koa/Express (Google в помощь), однако я заметил, что все они содержат повторяющийся код для серверного рендеринга. Я решил упростить задачу и выделить этот общий код в библиотеку, так и появился на свет Create React Server, работает примерно так:

import Express from "express";
import config from "./webpack.config";
import createRouter from "./src/createRouter";
import createStore from "./src/createStore";
import {createExpressServer} from "create-react-server";

createExpressServer({
  createRouter: (history) => (createRouter(history)),
  createStore: ({req, res}) => (createStore()),
  port: 3000
}));

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

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

Всем привет! Продолжение противостояния 2х языков.

Сегодня у нас будет более честное сравнение, которое отображает большинство реальных задач.
Итак, мы сегодня сравним PHP и Node.js по следующим признакам:

1. Типичная динамическая страница
2. REST API

В последнее время в сети довольно часто упоминается «молодой и перспективный» язык Rust. Он пробудил во мне любопытство и желание сделать на нём что-то более-менее полезное, чтобы как-то примерить — впору ли он мне. Это вылилось в достаточно любопытный, как мне кажется, опыт скрещивания ужа с ежом при содействии кукушки.

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

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

Для некоего личного проекта мне захотелось написать бота с довольно сложной ветвящейся логикой (например, это может быть система поддержки или диагностики с глубокой вложенностью). При этом граф данной логики имеет огромное количество разветвлений. В общем, быстро стало очевидно, что без автоматизированного тестирования не обойтись — иначе что-то точно упущу из внимания. И насколько же сильно я удивился, когда узнал, что способа тестировать логику ботов просто нет!

Конечно, можно зарегистрировать дополнительного бота для тестирования, но это вариант кривой и некрасивый. Обращение ко внешнему апи во время тестов, заглушка, которая не даст общаться с ботом кому попало, ограничение на скорость отправки сообщений раз в секунду… Если слать сообщение раз в секунду, то граф из каких-то 60 вершин будет тестироваться уже больше минуты! И я уже не говорю о том, что у нас нет никакой возможности смоделировать возросшую нагрузку на бота, при которой он упрётся в ограничение в 30 сообщений в секунду… В общем, я понял, что опять придётся делать что-то своё.

Маленькое введение. Скорее всего этот пост будет интересен только тем, кто знает, что такое ESLint, но всё же сделаю небольшую вводную — а то сам сильно расстраиваюсь, когда открываю публикацию, и она начинается словами “уже 10 лет мы используем ххх, о котором вы конечно же знаете, а написать мы решили про xxx.yyy, что никто никогда не делал, но наверняка это очень круто”.

Итак, ESLint это крутой инструмент, который позволяет проводить анализ качества вашего кода, написанного на любом выбранном стандарте JavaScript. Он приводит код к более-менее единому стилю, помогает избежать глупых ошибок, умеет автоматически исправлять многие из найденных проблем и отлично интегрируется со многими инструментами разработки (привет, Jetbrains, мы любим вас!). Кстати, он, как и другие линтеры, не обязывает вас к одному какому-то конкретному стилю. Наоборот — вы можете выбрать что-то из лучших практик и доработать по своему усмотрению!

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

Все началось примерно 6 лет назад, когда я познакомился с node.js. Около 3 лет назад я начал использовать node.js на проектах вместе с замечательной библиотекой express.js (на wiki она названа каркасом приложений, хотя некоторые могут называть express фреймворком или даже пакетом). Express сочетает в себе node.js http сервер и систему промежуточного ПО, созданную по образу каркаса Sinatra из Ruby.

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



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

Вот основные темы, которые мы здесь раскроем:

• Разработка хорошо масштабируемых приложений, которые легко поддерживать.
• Качественное разделение конфигурационных данных и основного кода приложения.
• Использование в Node.js-приложениях процессов различных типов.

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

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

Взять хотя бы оповещения от Twisst ISS бота, который отправляет вам сообщение каждый раз, когда Международная космическая станция (МКС) будет видна из вашего местоположения.



Или боты публичных сервисов наподобие Earthquake Robot, который отправляет твит о подземных толчках более 5 баллов по шкале Рихтера, как только они случаются.

Ну и конечно, poem.exe, робот, который постит стихотворения, а также Accidental Haiku, который ретвитит посты, случайно написанные в форме хайку.

Всё гениальное просто. Но до этой простоты нужно перечитать тысячи мануалов. Поэтому, разобравшись, мне захотелось написать quick start по тому, как сделать прозрачную авторизацию в Web-приложении для пользователя, авторизованного в AD, и поделиться своим тестовым проектом. Интересен взгляд со стороны.

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



Мне довелось поучаствовать в работе над этим проектом в качестве консультанта. Посещаемость ресурса составляет порядка 200 миллионов уникальных пользователей в месяц. Такая популярность означает и высокий уровень рисков в сфере информационной безопасности, в частности, это риск подвергнуться различным видам атак, самые распространённые среди которых – DDoS. Организация, которую называть не буду, внедрила широкий спектр решений для предотвращения воздействия подобных атак на работоспособность сервиса.

В жизни каждого Java разработчика может наступить момент, когда ничего не остаётся, как использовать в своём приложении ReactJS. Если, конечно, не AngularJS. Вы долго сопротивлялись, но этот момент настал и надо что-то делать. Вы слышали, что есть Node.JS, что он умеет быть web-сервером, но это уже через чур. У вас будет кошерный Spring Boot. К сожалению, поиск в гугл способен очень запутать. Много разных гайдов, все оперируют разными версиями реакта и сопутствующих средств. Данный гайд описывает процесс создания простейшего Spring Boot + ReactJS приложения, простой и приятный.

При создании смарт контрактов на платформе Ethereum разработчик закладывает определенную логику работы, определяющую как методы должны изменять состояние контракта, какие должны эмитироваться события, когда и кому нужно произвести перевод средств, а когда бросить исключение. Инструменты отладки смарт контрактов еще не очень развиты, поэтому тесты зачастую становятся необходимым инструментом разработки, т.к. запускать контракты после каждого изменения может быть достаточно долгой процедурой. Также, в случае обнаружения ошибок, изменить код развернутого в сети контракта уже невозможно, можно только уничтожить контракт и создать новый, поэтому тестирование стоит проводить максимально подробно, особенно методы связанные с платежами. В статье будут показаны некоторые приемы тестирования, с которыми сталкиваются разработчики при создании и отладке смарт контрактов на Solidity.

Технология Node.js всё еще молода и в то же время существует достаточно долго, чтобы крупные корпорации (LinkedIn, Yahoo! и Netflix) взяли ее на вооружение.

Эта книга посвящена Node и тем модулям, которые образуют базовую функциональность Node. Вы начнете знакомство с основ создания веб-сервера и базовых функциональностей, а затем перейдете к системе модулей, REPL, разработке приложений, проблемам безопасности, дочерним процессам, познакомитесь с новыми функциональностями, появившимися в ES6, комплексной разработкой (Express, MongoDB, Redis, AngularJS и Backbone.js), приемами разработки приложений и, наконец, с использованием Node в других областях, таких как микроконтроллеры и «интернет вещей».

Статья представляет собой пошаговое описание моего опыта создания кроссплатформенного десктопного приложения с помощью Webix, Electron и Node.js.

Однажды мне пришла в голову светлая мысль создать десктопное приложение на базе стека веб-технологий, который мне хорошо знаком. Знаю, что программисты, пишущие под десктоп, обычно используют C++, Java, C#, а на стек веб-технологий для этих целей смотрят свысока. Но, поскольку я писал приложение для себя, то справедливо решил, что использование знакомых инструментов ускорит процесс. Ну и конечно захотелось «скрестить ужа с ежом» и посмотреть что получится. Если вкратце, то получившийся результат можно запускать и как обычное веб-приложение, и как десктоп.

Код уже готового приложения можно скачать с GitHub.