Руководство для начинающих по серверной веб-разработке с Node.js
Большую часть своей веб-карьеры я работал исключительно на стороне клиента. Проектирование адаптивных макетов, создание визуализаций из больших объемов данных, создание инструментальных панелей приложений и т. Д. Но мне никогда не приходилось иметь дело с маршрутизацией или HTTP-запросами напрямую. До не давнего времени.
Этот пост представляет собой описание того, как я узнал больше о веб-разработке на стороне сервера с помощью Node.js, и краткое сравнение написания простого HTTP-сервера с использованием 3 разных сред, Express, Koa.js и Hapi.js.
Примечание: если вы опытный разработчик Node.js, вы, вероятно, подумаете о том, что это все элементарно/просто. ¯\_(ツ)_/¯.
Некоторые основы сети
Когда я начал работать в веб-индустрии пару лет назад, я наткнулся на курс по компьютерным сетям профессора Дэвида Ветерала на Coursera. К сожалению, он больше не доступен, но лекции по-прежнему доступны на веб-сайте Pearson.
Мне очень понравился этот курс, потому что он объяснял, что происходило под капотом, в понятной форме, поэтому, если вы можете взять в руки учебник «Компьютерные сети», прочитайте все подробности о чудесах сети.
Здесь, однако, я собираюсь лишь кратко рассказать о контексте. HTTP (Hypertext Transfer Protocol) — это протокол связи, используемый в компьютерных сетях. В Интернете их много, таких как SMTP (простой протокол передачи почты), FTP (протокол передачи файлов), POP3 (протокол почтового отделения 3) и так далее.
Эти протоколы позволяют устройствам с совершенно разным аппаратным / программным обеспечением связываться друг с другом, поскольку они предоставляют четко определенные форматы сообщений, правила, синтаксис и семантику и т.д. Это означает, что, пока устройство поддерживает определенный протокол, оно может связываться с любым другим устройством. в сети.
От TCP / IP против OSI: в чем разница между двумя моделями?
Операционные системы обычно поставляются с поддержкой сетевых протоколов, таких как HTTP, из коробки, что объясняет, почему нам не нужно явно устанавливать какое-либо дополнительное программное обеспечение для доступа в Интернет. Большинство сетевых протоколов поддерживают открытое соединение между двумя устройствами, что позволяет им передавать данные туда и обратно.
HTTP, на котором работает сеть, отличается. Он известен как протокол без установления соединения, потому что он основан на режиме работы запрос / ответ. Веб-браузеры отправляют на сервер запросы на изображения, шрифты, контент и т.д., но после выполнения запроса соединение между браузером и сервером разрывается.
Servers and Clients
Термин сервер может слегка сбивать с толку людей, впервые знакомых с отраслью, поскольку он может относиться как к аппаратному обеспечению (физические компьютеры, на которых размещены все файлы и программное обеспечение, требуемое веб-сайтами), так и к программному обеспечению (программе, которая позволяет пользователям получать доступ к этим файлам в Интернете).
Сегодня мы поговорим о программной стороне вещей. Но сначала несколько определений. URL обозначает Universal Resource Locator и состоит из 3 частей: протокола, сервера и запрашиваемого файла.
Структура URL адреса
Протокол HTTP определяет несколько методов, которые браузер может использовать, чтобы попросить сервер выполнить кучу различных действий, наиболее распространенными из которых являются GET и POST. Когда пользователь щелкает ссылку или вводит URL-адрес в адресную строку, браузер отправляет GET-запрос на сервер для получения ресурса, определенного в URL-адресе.
Сервер должен знать, как обрабатывать этот HTTP-запрос, чтобы получить правильный файл, а затем отправить его обратно браузеру, который его запросил. Наиболее популярное программное обеспечение веб-сервера, которое обрабатывает это Apache и NGINX.
Веб-серверы обрабатывают входящие запросы и отвечают на них соответственно
Оба представляют собой полнофункциональные пакеты программного обеспечения с открытым исходным кодом, которые включают в себя такие функции, как схемы аутентификации, перезапись URL-адресов, ведение журнала и проксирование, и это лишь некоторые из них. Apache и NGINX написаны на C. Технически, вы можете написать веб-сервер на любом языке. Python, golang.org/pkg/net/http, Ruby, этот список может продолжаться довольно долго. Просто некоторые языки лучше выполняют определенные вещи, чем другие.
Создание HTTP сервера с Node.js
Node.js — это среда выполнения Javascript, построенная на движке Chrome V8 Javascript. Он поставляется с модулем http, который предоставляет набор функций и классов для построения HTTP-сервера.
Для этого базового HTTP-сервера мы также будем использовать файловую систему, путь и URL-адрес, которые являются собственными модулями Node.js.
Начните с импорта необходимых модулей.
Мы также создадим словарь типов MIME, чтобы мы могли назначить соответствующий тип MIME запрашиваемому ресурсу на основе его расширения. Полный список типов MIME можно найти в Internet Assigned Numbers Authority (интернет-центре назначенных номеров).
Теперь мы можем создать HTTP-сервер с функцией http.createServer() , которая будет возвращать новый экземпляр http.Server .
Мы передадим функцию-обработчик запроса в createServer() с объектами запроса и ответа. Эта функция вызывается один раз каждый раз, когда к серверу поступает HTTP-запрос.
Сервер запускается путем вызова метода listen объекта server с номером порта, который мы хотим, чтобы сервер прослушивал, например, 5000 .
Объект request является экземпляром IncomingMessage и позволяет нам получать доступ ко всей информации о запросе, такой как статус ответа, заголовки и данные.
Объект response является экземпляром ServerResponse, который является записываемым потоком и предоставляет множество методов для отправки данных обратно клиенту.
В обработчике запросов мы хотим сделать следующее:
- Разобрать входящий запрос и обработать его без расширений
Выполните некоторые элементарные проверки, чтобы определить, существует ли запрошенный ресурс, и ответить соответственно
Весь код размещен на Glitch, и вы можете сделать ремикс на проект, если хотите.
Создание HTTP-сервера с фреймворками Node.js
Фреймворки Node.js, такие как Express, Koa.js и Hapi.js, поставляются с различными полезными функциями промежуточного программного обеспечения, в дополнение к множеству других удобных функций, которые избавляют разработчиков от необходимости писать самим.
Лично я чувствую, что лучше сначала изучать основы без фреймворков, просто для понимания того, что происходит под капотом, а затем после этого сходить с ума с любым фреймворком, который вам нравится.
В Express имеется собственный встроенный плагин для обслуживания статических файлов, поэтому код, необходимый для выполнения тех же действий, что и в собственном Node.js, значительно короче.
Koa.js не имеет подобного плагина внутри своего ядра, поэтому любой требуемый плагин должен быть установлен отдельно. Последняя версия Koa.js использует асинхронные функции в пользу обратных вызовов. Для обслуживания статических файлов вы можете использовать плагин koa-static .
Hapi.js поддерживает настройку и вращается вокруг настройки объекта server . Он использует плагины для расширения возможностей, таких как маршрутизация, аутентификация и так далее. Для обслуживания статических файлов нам понадобится плагин с именем inert .
У каждой из этих платформ есть свои плюсы и минусы, и они будут более очевидными для более крупных приложений, а не просто для обслуживания одной HTML-страницы. Выбор структуры будет сильно зависеть от реальных требований проекта, над которым вы работаете.
Источник
Почему не работает node js?
npm ERR! code EACCES
npm ERR! syscall symlink
npm ERR! path ../lib/node_modules/browser-sync/dist/bin.js
npm ERR! dest /usr/local/bin/browser-sync
npm ERR! errno -13
npm ERR! Error: EACCES: permission denied, symlink ‘../lib/node_modules/browser-sync/dist/bin.js’ -> ‘/usr/local/bin/browser-sync’
npm ERR! [OperationalError: EACCES: permission denied, symlink ‘../lib/node_modules/browser-sync/dist/bin.js’ -> ‘/usr/local/bin/browser-sync’] <
npm ERR! cause: [Error: EACCES: permission denied, symlink ‘../lib/node_modules/browser-sync/dist/bin.js’ -> ‘/usr/local/bin/browser-sync’] <
npm ERR! errno: -13,
npm ERR! code: ‘EACCES’,
npm ERR! syscall: ‘symlink’,
npm ERR! path: ‘../lib/node_modules/browser-sync/dist/bin.js’,
npm ERR! dest: ‘/usr/local/bin/browser-sync’
npm ERR! >,
npm ERR! stack: «Error: EACCES: permission denied, symlink ‘../lib/node_modules/browser-sync/dist/bin.js’ -> ‘/usr/local/bin/browser-sync'»,
npm ERR! errno: -13,
npm ERR! code: ‘EACCES’,
npm ERR! syscall: ‘symlink’,
npm ERR! path: ‘../lib/node_modules/browser-sync/dist/bin.js’,
npm ERR! dest: ‘/usr/local/bin/browser-sync’
npm ERR! >
npm ERR!
npm ERR! The operation was rejected by your operating system.
npm ERR! It is likely you do not have the permissions to access this file as the current user
npm ERR!
npm ERR! If you believe this might be a permissions issue, please double-check the
npm ERR! permissions of the file and its containing directories, or try running
npm ERR! the command again as root/Administrator.
npm ERR! A complete log of this run can be found in:
npm ERR! /Users/user/.npm/_logs/2020-02-06T12_39_46_249Z-debug.log
Потом я решил проверить что npm вообще может делать, но он игнорит все команды выдавая ERR или WARN. Перерыл весь интернет со вчерашнего дня, никакие команды не работают. Переустанавливал 3 раза, обычную и Current версию. Бесполезно.
Пробывал устанавливать не глобально, a терминал писал:
Источник
Как совершить транзакцию в Nest.js
Во множестве случаев разработчики должны использовать транзации при совершении различных операций на сервере. К примеру — перевод денег, либо другой измеримой ценности, да много чего еще. При таких операциях очень не хочется получить ошибку, которая прервет процесс и нарушит целостность данных.
А что вообще такое «транзакция»? Википедия говорит нам, что это — группа последовательных операций с базой данных, которая представляет собой логическую единицу работы с данными. Транзакция может быть выполнена либо целиком и успешно, соблюдая целостность данных и независимо от параллельно идущих других транзакций, либо не выполнена вообще, и тогда она не должна произвести никакого эффекта. Транзакции обрабатываются транзакционными системами, в процессе работы которых создаётся история транзакций.
Теперь, рассмотрим ситуацию, когда может произойти ошибка, ведущая к очень неприятным последствиям, если не использовать транзакции.
Я сделал небольшой проект, в котором есть две сущности:
Пользователи могут переводить друг другу деньги. При переводе проверяется достаточность суммы на балансе того, кто переводит, а также много других проверок. Если произойдет ситуация, когда с баланса отправителя деньги списаны, а на счет получателя не переведены, либо наоборот — мы увидим либо очень грустного, разъяренного человека, либо не увидим очень счастливого (зависит от суммы перевода).
Отлично, с тем, что транзакции важны и нужны разобрались (надеюсь, с этим согласны все). Но как их применять?
Для начала рассмотрим варианты запросов с ошибками и без ошибок, которые будут происходить, если использовать PostgreSQL.
Обычный набор запросов без ошибок:
К слову — этот запрос я не писал руками, а вытащил из логов ORM, но суть он отражает. Все довольно просто и понятно. Для построения запросов использовалась TypeORM, к которой мы вернемся немного позднее.
Настройки ORM и Postgres выставлены по умолчанию, поэтому каждая операция будет выполняться в своей транзации, но чтобы воспользоваться этим преимуществом, необходимо написать один запрос, в котором будет происходить сразу вся логика, связанная с базой данных.
Ниже приведен пример исполнения нескольких запросов, исполняемых в одной транзакции:
Ключевая разница с предыдущим примером запросов в том, что в данном случае все запросы выполняются в одной транзакции, а поэтому, если на каком-то этапе возникнет ошибка, то откатится вся транзакция со всеми запросами внутри нее. Примерно так:
А вот, кстати, и код, который производил все предыдущие SQL-запросы. В нем имеется флаг, при установке которого возникает ошибка в самых неподходящий момент:
Отлично! Мы уберегли себя от убытков или очень огорченных пользователей (по крайней мере в вопросах, связанных с переводами денег).
Другие способы
Что дальше? Какие еще есть способы написать транзакцию? Так уж получилось, что человек, статью которого вы сейчас читаете (это я) очень любит один замечательный фреймворк, когда ему приходится писать backend. Имя этому фреймворку — Nest.js. Работает он на платформе Node.js, а код в нем пишется на Typescript. В этом прекрасном фреймворке имеется поддержка, практически из коробки, той самой TypeORM. Которая (или который?) мне, так уж получилось, тоже очень нравится. Не нравилось только одно — довольно запутанный, как мне кажется, излишне усложненный подход к написанию транзакций.
Это официальный пример по написанию транзакций:
Второй способ создания транзакций из документации:
В целом, смысл этого подхода заключается в следующем: вам необходимо получить transactionEntityManager: EntityManager — сущность, которая позволит выполнять запросы в рамках транказции. А затем использовать эту сущность для всех действий с базой. Звучит неплохо, до тех пор, пока не придется столкнуться с использованием данного подхода на практике.
Для начала — мне не очень нравится идея прокидывания зависимостей непосредственно в методы классов-сервисов, а также то, что написанные таким образом методы становятся обособленными в части использования вн едренных в сам сервис зависимостей. Все необходимые для работы метода зависимости придется в него же и прокидывать. Но самое неприятное — если ваш метод будет обращаться к другим сервисам, внедренным в ваш, то вам придется создавать такие же специальные методы в тех сторонних сервисах. И в них же передавать transactionEntityManager . При этом, стоит иметь в виду то, что если вы решили использовать подход через декораторы, то при передаче transactionEntityManager из одного сервиса во второй, и метод второго сервиса будет также отдекорирован — во втором методе вы получите не переданный в качестве зависимости transactionEntityManager , а тот, что создается декоратором, а значит — две разные транзакции, а значит горе-пользователей.
Начнем с примеров
Ниже показан код экшена контроллера, обрабатывающего пользовательские запросы:
В нём нам необходимо иметь доступ к объекту соединения connection , чтобы создать transactionManager . Мы могли бы поступить, как советуют в документации к TypeORM — и просто использовать функцию getConnection , как было показано выше:
Но сдается мне, что такой код будет тестироваться уже сложнее, да и это просто неправильно (отличный аргумент). Поэтому нам придется прокидывать зависимость connection в конструктор контроллера. Очень повезло, что Nest позволяет это сделать просто описав поле в конструкторе с указанием соответствующего типа:
Таким образом мы приходим к выводу, что чтобы иметь возможность использовать транзакции в Nest при использовании TypeORM — необходимо прокидывать в конструктор контроллера / сервиса — класс connection , пока просто запомним это.
Теперь посмотрим на метод makeRemittanceWithTypeOrmV1 нашего appService :
Весь проект синтетический, но чтобы показать неприятность сего подхода — я вынес в отдельный сервис appServiceV2 метод savePurse , используемый для сохранения кошелька, и использовал этот сервис с этим методом внутри рассматриваемого метода makeRemittanceWithTypeOrmV1 . Код данного метода и сервиса вы можете увидеть ниже:
Собственно, при этой ситуации мы получаем такие SQL-запросы:
Если мы отправим запрос, чтобы происходила ошибка, то явно увидим, что внутренняя транзакция, от appServiceV2 не откатывается, а поэтому — мы огребаем от наших пользователей.
Тут мы делаем вывод, что для стандартного подхода к транкациям необходимо иметь специальные методы, в которые будет нужно прокидывать transactionEntityManager .
Если же мы хотим избавиться от необходимости явного внедрения transactionEntityManager в соответствующие методы — то документация советует нам взглянуть на декораторы.
Применив их мы получим такого вида экшен контроллера:
Теперь он стал проще — нет необходимости в использовании класса connection , ни в конструкторе, ни вызывая глобальный метод TypeORM. Прекрасно. Но метод нашего сервиса, по прежнему, должен получать зависимость — transactionEntityManager . Тут на помощь и приходят те самые декораторы:
С тем, что простое использование метода стороннего сервиса ломает наши транзакции — мы уже разобрались. Поэтому мы использовали новый метод стороннего сервиса transactionEntityManager , который имеет следующий вид:
Как видно из кода, в данном методе мы также применили декораторы — так мы достигаем единообразия по всем методам в проекте (ага), а также избавляемся от необходимости использования connection в конструкторе контроллеров, использующих наш сервис appServiceV2 .
При таком подходе мы получаем такие запросы:
И, как следствие — разрушение транзакции и логики приложения при ошибке:
Единственный рабочий способ, который описывает документация — это отказ от использования декораторов, т.к. если использовать декораторы во всех методах сразу — то в те из них, что будут использоваться другими сервисами, будут внедрены свои собственные transactionEntityManager ‘ы, как это произошло с нашим сервисом appServiceV2 и его методом savePurseInTransaction . Попробуем заменить данный метод другим:
Т.к. для единообразия наших методов, и избавления появившейся иерархии, проявляющейся в том, что одни методы могут вызывать другие, но третьи не смогут вызывать первые — мы изменим и метод класса appService , придя к первому способу из документации.
Рояль в кустах
Что же, кажется, нам все равно придется внедрять этот connection в конструкторы контроллеров. Но предлагаемый способ написания кода с транзакциями по прежнему выглядит очень громоздким и неудобным. Что делать? Решая данную неприятность я сделал пакет, который позволяет наиболее простым способом использовать транзакции. Называется он nest-transact.
Что он делает? Тут все просто. На нашем примере с пользователями и переводами посмотрим на ту же логику, написанную с помощью nest-transact.
Код нашего контроллера не изменился, и, раз уж мы убедились в том, что без connection в конструкторе не обойтись — укажем его:
Его отличие от экшена, в случае использования первого способа из документации:
В том, что мы можем использовать обычные методы сервисов, не создавая специфические вариации для транзакций, в которые необходимо прокидывать transactionManager . А также — что перед использованием нашего бизнес-метода сервиса, мы вызываем метод withTransaction , на этом же сервисе, передавая в него наш transactionManager . Тут можно задаться вопросом — откуда взялся этот метод? Отсюда:
А вот и код запросов:
Но вы его уже видели в самом начале.
Чтобы эта магия заработала — нужно выполнить два шага:
Наш сервис должен наследоваться от класса TransactionFor
Наш сервис должен иметь в списке зависимостей конструктора специальный класс moduleRef: ModuleRef
Все. Кстати, т.к. внедрение зависимостей самим фреймворком никуда не делось — явно прокидывать moduleRef не придется. Только при тестировании.
Возможно, вы подумаете — А зачем мне наследоваться от этого класса? Вдруг мой сервис должен будет наследоваться от какого-то другого? Если подумали — то предлагаю посчитать, сколько ваших сервисов отнаследованы от других классов, и используются при транзакциях.
Теперь, как это работает? Появившийся метод withTransaction — пересоздает для данной транзакции ваш сервис, а также все зависимости вашего сервиса и зависимости зависимостей — всё, всё, всё. Отсюда следует, что если вы каким-то образом храните некое состояние в ваших сервисах (ну а вдруг?) — то его не будет при создании транзакции таким образом. Оригинальный инстанс вашего сервиса все так же существует и при его вызове все будет как и раньше.
В дополнение к предыдущему примеру я добавил и жадный метод: перевод с комиссией, в котором используются сразу два сервиса в одном экшене контроллера:
Этот метод производит следующие запросы:
Из которых мы видим, что все запросы, по прежнему, происходят в одной транзации и работать она будет корректно.
Источник
