Источник: Nuances of Programming
Не хочу разводить очередной холивар на эту тему. Поэтому, если вкратце, то GraphQL — это сложно, RPC — быстро, REST — некий медиум, но не хватает batch-запросов. И если у вас небольшое приложение или микросервис, то rpc, он же “вызов удаленной процедуры”, может оказаться гораздо лучше и экономичнее для вашей архитектуры, особенно если она основана на микросервисном подходе.
Итак, давайте подробнее разберем JSON RPC v2.0
Спецификация достаточно проста и лаконична.
На моей практике это решение оказалось достаточно удобным и простым, но при этом мощным и расширяемым. И меня сильно удивило, что в мире node.js оно применяется крайне редко.
Суть подхода достаточно примитивна
Запрос включает в себя 4 поля:
- jsonrpc — всегда будет “2.0”, указывает версию протокола.
- method — название метода (функции), который нужно вызвать.
- params — опциональное поле, нагрузка к вызову (аргументы функции).
- id — опциональное поле, уникальный идентификатор вызова. Если вы хотите получить значение от вызванной функции, то вы должны сгенерировать id на стороне клиента и при ответе вы сможете понять, на какой именно вызов пришел ответ, сопоставив id ответа.
Если вы не отправили id, то это означает, что ответ вас не интересует и от сервера вы ничего не получите. Такой вызов называется нотификацией.
Ответ может иметь следующие поля:
- jsonrpc — всегда будет “2.0”, указывает версию протокола.
- result — тело ответа (возвращаемое значение функции).
- id — уникальный идентификатор ответа. Он нужен для того, чтобы клиент мог сопоставить, на какой запрос он получил ответ.
- error — в случае ошибки вместо result, вы получите поле error, содержащее в себе code (код ответа: по протоколу их может быть шесть) и message (человекопонятное описание ошибки).
Вишенка на торте — это Batch-запрос!
Это означает, что мы можем слепить несколько отдельных ajax запросов в один и отдать его серверу в виде массива запросов. А при получении по заданным id мы поймем, на какой запрос получили ответ.
Небольшая тонкость!
Учтите, что по протоколу сервер не гарантирует последовательность элементов в ответе, например:
> [{id:1}, {id:2}, {id:3}]
<-[{id:2}, {id:1}, {id:3},]
Будет считаться вполне нормальным ответом, т.к. время выполнения функций разное, и сервер заполняет массив ответами по мере их асинхронного выполнения.
Поэтому клиент сам должен промапить ответ и сопоставить id каждого элемента в ответе с запросом.
Давайте уже писать код!
Поскольку в последнее время я пишу на node.js и готового решения, которое бы полностью меня устроило, я не нашел, то я решил запилить простой JSON-RPC роутер для express.js без каких либо зависимостей.
https://www.npmjs.com/package/express-json-rpc-router
В документации к пакету базовые примеры уже рассмотрены. Давайте придумаем вариант посложнее.
Например, создадим сервер с тремя методами, которые будут получать данные по http от другого ресурса. Каждый метод будет проверять, что пользователь ввел валидные параметры, затем выполнять тело метода и логировать результат выполнения в файл.
У нас имеется три основных объекта:
methods — наши JSON-RPC методы, функции которые реализуют основную логику. Это могут быть ваши контроллеры.
beforeMethods (опциональные) — хук, который будет вызван перед выполнением метода. Здесь вы можете валидировать переданные параметры и выкидывать ошибки, которые попадут в вышестоящий обработчик. Название хука должно совпадать с названием метода, к которому этот хук относится, иначе будет вызвано исключение с сообщением, содержащим информацию о том, какой хук был назван неправильно.
afterMethods (опционально) — хук, который по своей логике похож на предыдущий. Разница только в том, что он будет вызван после выполнения метода и в качестве второго параметра получит результат выполнения. Может быть удобен для логгирования запросов.
Также предоставлен callback (onError) — функция, в которую будет передана ошибка, если она случилась. Тут можно удобно подключить логгер ошибок вроде sentry.io.
Обратите внимание, что bodyParser вызван перед роутером. Можете использовать другой вариант парсинга тела запроса, главное, чтобы в req.body мы получили параметры запроса в формате JSONRPC.
Библиотека в стадии разработки, так что если у вас есть пожелания или идеи, смело пишите в комментариях или открывайте github issues.
Всем хорошего настроения!
Читайте нас в телеграмме и vk