Что нужно учитывать при создании серверной части с помощью Node.js?

Давайте рассмотрим, как создать серверную систему с помощью Node.js. Прежде чем углубиться в тему, я хочу объяснить несколько важных концепций, чтобы мы знали минимальное количество терминов/понятий при построении серверной системы.

Что такое REST API?

Байскально можно сказать, что это REST + API. REST — это передача репрезентативного состояния, и это один из типов программных архитектур для гипермедиа-систем. Архитектура относится к передаче ресурсов Интернета через HTTP без сложных уровней передачи. API — это интерфейс прикладного программирования, представляющий собой набор определений подпрограмм, протоколов и инструментов для создания прикладного программного обеспечения. Это набор четко определенных методов связи между различными программными компонентами.

Стиль архитектуры REST?
1. Клиент-сервер

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

2. лицо без гражданства

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

3. кеш

Кэширование должно быть. Мы можем использовать Last-modified или E-tag для кэширования.

4. единый интерфейс

необходимо использовать URI для выбора ресурса с определенным интерфейсом

5. многоуровневая система

Сервер REST может иметь несколько уровней: уровни безопасности, балансировки нагрузки и шифрования, чтобы иметь мягкую структуру, а также PROXY и шлюз в качестве промежуточного программного обеспечения.

Слава ОТДЫХА

Выше представлена ​​Модель зрелости Ричардсона Мартина Фаулера, которая показывает шаги к более совершенной системе REST. По сути, по мере того, как вы поднимаетесь на уровень 3, система становится более RESTful. Теперь давайте кратко подойдем к ступенькам.

Уровень0

Сама конечная точка относится к одной службе. Он не использует веб-механизмы, а использует HTTP как простую систему передачи удаленной связи, аналогичную RPC (удаленный вызов процедур). Проще говоря, клиент может вызывать методы, определенные на сервере, и наоборот. Это помогает максимально скрыть подробную информацию при общении с серверами.

Уровень 1

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

Уровень 2

Глаголы HTTP включают: POST, GET, PUT, DELETE, и с этими доступными действиями один и тот же URI может иметь разные значения, что делает URI двумерным.

Уровень 3

Мы можем думать о Hypermedia Links как о HATEOAS. Это означает, что управление состоянием клиента с помощью ссылок. Состояние клиента представлено URI, а изменение состояния представлено ответом сервера HATEOAS. Я могу объяснить разницу между уровнем 2 и уровнем 3 на примере REST API. Допустим, мы вызываем API для получения всех пользователей с запросом на получение и uri для /users. На уровне 2 мы получим все идентификаторы пользователей, и чтобы увидеть подробную информацию о каждом пользователе, мы можем просто вызвать /users/${user_id}. Но это всего лишь наше предположение. Нам нужно убедиться, что такой URI существует, и это то, что HATEOAS делает для нас с помощью Link. Когда мы запрашиваем с помощью запроса GET, в ответ HATEOAS возвращает что-то вроде следующего:

Потому что мы уверены, что получим подробную информацию о продукте с запросом /product/1.

Аутентификация!

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

HTTP является протоколом без сохранения состояния и не сохраняет никакой информации. В HTTP-запросе должен существовать идентификатор сеанса, который является ключом и будет сопоставлен со значением (информацией пользователя) в базе данных в памяти, такой как Redis. Давайте исследуем картинку выше. Сервер, получив запрос от клиента, должен сохранить информацию о пользователе, поэтому создает сеанс, и в сеансе есть идентификатор сеанса, который будет возвращен как базе данных (redis), так и клиенту (cookie). В этом случае, как только пользователь будет аутентифицирован, в следующий раз, когда он/она захочет войти в систему, он может использовать файл cookie со стороны клиента для аутентификации, и ему не нужно будет снова входить в систему.

Проблемы?

Конечно, проблема существует! Сессия использует память сервера и требует масштабирования. Кроме того, при возникновении ошибки на стороне сервера вся информация о сеансе теряется.

Решения?

Кластеры сеансов: все серверы совместно используют сеансы. Как и в приведенном выше примере, мы можем использовать базу данных распределения в памяти, такую ​​​​как Redis, и это позволяет получать сеанс с других рабочих серверов, когда один сервер не работает. Благодаря этому мы освобождаемся от закрепленных сеансов. Однако это также может быть проблемой, если сервер Redis не работает, поэтому необходимо учитывать реплики этого сервера Redis. (Боль CS!)

Паспорт?

Passport — это промежуточное ПО, которое мы можем использовать в nodejs для аутентификации. Это промежуточное ПО проверяет, может ли клиент отправить запрос на сервер. Используя это промежуточное программное обеспечение, мы можем легко проверить, допустимы ли некоторые запросы к серверу.

Вывод

Теперь мы рассмотрели концепции REST API с сеансом. Наконец, вкратце пробежался по модулю паспорта, чтобы увидеть, как работать с бэкендом с помощью nodejs, используя javascript. Надеюсь, эта статья поможет всем, и если у вас есть какие-либо комментарии, пожалуйста, прокомментируйте статьи для плодотворного обсуждения!