Comments 16
— Интересно есть плагин чтобы из браузера просматривать запросы/ответы в удобоваримом виде?У вас ещё добавляется отсутсвие автогенерации клиента.
— Плюс для простых случаев, для REST можно через какой-нибудь API прокси делать интересные вещи без изменений бэкенда, а с протобуфером конечно сильно сложнее по сравнению с json.
— Для манипулирования данными гораздо интереснее конечно что-то типа odata/graphql.
— Ну и самый большой недостаток, людей знающих как это всё заставить взлететь сильно меньше, так что если это не твой личный проект, то десять раз подумаешь прежде чем вкорячивать подобное.
Плюс в статье отсутсвуют данные про сериализацию — какие стандарты поддерживаются? Какой-нибудь JSON-RPC можно запилить?
Обработка ошибок и возврат деталей о ошибках как реализован?
Плюс на сколько я понял у вас получается каждый API метод это отдельный класс?
По идее надо использовать языки с reflection, там можно небольшую обёртку навесить сверху и универсально обрабатывать вызовы, а тут у вас совсем велосипедно выходит, хоть и возраст очень солидный.
Я понял что статья не зашла (по крайней мере сообществу), все равно спасибо. Я не хотел писать трехтомный пост и углубляться в каждый уголок.
Да автогенерация отсутствует, но по факту, вам нужно писать только 1 отдельный класс для каждого метода. Обработка ошибок - если не усложнять, то блок try catch в котором находиться вызов всех слоев с отдельным классом ошибки.
Вот с сериализацией все гораздо интереснее, можно прикрутить json-rpc, а можно общаться xml (мало ли), можно доставать данные из get параметров и тд... По факту за это отвечают первые 3 слоя (откуда достать, как достать и какая структура) и они кладут вам все это в класс запроса метода.
Что такое Rpc в понимании автора, при чём тут API? Что это вообще было? У меня был свой велосипед для аутентификации пользователей 7-8 лет назад, может даже раньше. Сейчас он использует Redis (потому что у меня не миллион пользователей и так проще). Но я не пишу про это статьи на Хабре, потому что те, кто найдёт и будет пользоваться - я буду рад. Найдёт и укажет на ошибки, тем более буду рад. Ну а я просто пользуюсь.
Пример Rpc метода с авторизацией приведен для того чтоб показать как это можно оформить (не авторизацию, а сам метод). А основная суть, что мы его за 20-30 строк кода, оформляем в полноценный метод который можно вызвать клиентом (при чем с валидацией данных), например так:
{ "method": "auth", "auth": {"login": "test@mail.ru", "password": "12345678"} }Если так не устраивает пример, можете использовать JSON-RPC 2.0 Specification.
Зачем велосипеды , есть уже готовые решения https://github.com/vmkteam/zenrpc, авторы русские .
https://github.com/vmkteam/rpcgen генератор Клиента
С го не работал, но вот для с++ есть вполне приличная библиотека rpclib. Она кроссплатформенная, не требует IDL и компилятора в отличие от grpc, да и заводится клиент и сервер с полпинка...
И с rpc в итоге намного проще, чем ручками запросы парсить и шуровать :)
Вот и встретились 2 львенка, сорри за оффтоп, не удержался.
Мне казалось, что RPC в первую очередь протокол. Где его описание? Как передаются данные, поверх TCP, HTTP? В каком формате: JSON, Binary, XML или может что-то своё? Запускать просто нужный метод - это не совсем большая проблема...
Увы, но это не протокол, как и REST. Просто набор каких то размытых правил. Дальше есть надстройки как протокол SOAP, спецификация JSON-RPC 2.0 и не будем упускать gRPC. Я так понял народу больше интересно первые три слоя, которые размывают границу, как передается, в каком формате и в какой структуре.
Потому что от этого многое зависит. В хайлоаде частенько используют TCP или HTTP2 с бинарной сериализацией. Где перформанс не самое важное, можно и по HTTP 1.1 гонять JSON/XML и в этом случае сделать свою реализацию RPC ничего не стоит, это точно такой же контракт, как и в REST, который собственно и был создан заменой для RPC
Как по мне Rpc идет своим путем и этот путь менее популярен (пока что). В целом я видел проекты где есть и Rest и Rpc и они живут в одном проекте. А вот углубляться в сеть, когда это вопрос 50 строк кода и в формат данных (пусть еще 50 строк), это не целесообразно (для человека который пишет простой метод). Это вопрос оптимизации. Для браузера, мобильных приложений пока HTTP 1.1 + JSON, реже сокеты. Для общения между сервисами gRpc.
А теперь мы поднимаем образно 4 урла "/rpc" "/rest" "/soket" "/grpc" и один и тот же код работает везде (правда под rest и soket придется по мучаться дольше). Джуны пишут простые методы (getNewsList, getNewsById). Мидлы дописывают дополнительные валидационные штуки и другие более сложные вещи. Сеньеры решают что и как гонять, в каком формате, как настроить права доступа + другие попутные вещи.
А вывод, транспорт влияет на время выполнения, но никак не должен влиять на логику и нужно иметь возможность его поменять.
Я тоже давно делаю похожим образом. Отличие в том, что вместо явного описания метода я использую reflexion. То есть, просто написал функцию — и всё. Только их нужно все строго группировать — чтобы была возможность их все найти. За доставку запросов-ответов отвечают узлы вышестоящей подсистемы, которые делаю по мере надобности: для хттп одна, для socketio другая; для cli имеется, причем с автокомплитом под bash_completion. Недавно фронтовик попросил сделать генерацию схемы типов для typescript — запросто. Генерация js-клиента есть, документации и коллекции для постмана. В общем удобно. Но сообщество такие поделки не одобряет, это да )
И хотя я солидарен по сути вопроса, статья выглядит неполной какой-то. Идея изложена, но пюсов/минусов не видно, применения тоже. Типа, читайте сорцы
Я хотел написать чтиво выходного дня (чтоб народ мог подумать и не читать много). По большому счету это описание слоев (которые можно сделать на любом языке для rpc), пример как выглядит метод и немного о том, что не обязательно писать 500+ строк кода, ради одного метода. Про плюсы и минусы для Rpc - их уже озвучили тысячу раз.
Можно было бы углубиться, что схема для валидации это круто, удобно, многофункционально. Не обязательно получать из данных простые типы (например можно сразу получить объект пользователя по полю user_id), но это не изменит точку зрения людей. Пока не напишут свой велосипед, не успокоятся (увы такая реальность и это нормально). Не исключаю и поклонников готовых библиотек.
Говорить что json-rpc 2.0 морально устарел и его не хватает для нормального общения... это не для хабра...
Если про Go, то я столкнулся с проблемой, что первые 3 слоя влияют на слой валидации (если хочется оптимизации), но это детали языка. В целом соглашусь с тем, что генерация кода - это довольно интересная вещь, но это не популярно у простого народа на php и в ряде других языков (если не брать во внимание фреймворки), хотя в далекие времена писал сборщики js файлов и какие то мини генераторы.
статья выглядит неполной какой-то. Идея изложена, но пюсов/минусов не видно, применения тоже. Типа, читайте сорцы
Я хотел дописать какие то главы, но сейчас понимаю, что на это нет смысла тратить время, так же как и писать трехтомный пост. Про плюсы - гибкость (можно заменить слой в ядре, добавить или убрать), минусы - вам захочется или придется писать свой велосипед (для примера можно посмотреть сорцы). А лить воду, кидать кучу года из исходников, говорить "я сделал хранилище запросов" и другие банальные вещи - это не цель этой статьи.
В любом случае спасибо и я рад, что я не один такой)
Не совсем понял суть данной статьи, но автор, если тебе все еще интересен RPC в браузере, то сейчас помимо SOAP, JSON RPC и gRPC есть как минимум 2 варианта для Go:
1. twirp - от твитча, тот же gRPC только без реализации своего транспорта и net/http. Работает с stdlib. http/1.1 и http/2 и нет стримов, в отличии от gRPC, умеет по content-type сериализовать как в json так и protobuf. Описание API через protobuf. Валидация либо ручками, например через gowrap декораторы, либо можно protoc-get-validate использовать и описывать правила валидации прямо в protobuf.
2. connect-go - от bufbuild, создатели protoc-get-validate. Поддерживает стримы и совместим с grpc, вроде как тоже умеет в json.
И само собой оба фреймворка умеют в автогенерацию сервера и клиента.
Для себя и своих проектов выбрал twirp - завлекла его простота!)
RPC — концепция