Что-то вы усложняете. Для авторизации на сайте используется кука с флагами httpOnly, secure, path и другими. В ее подписи участвуют IP и User Agent. Ну и базовая защита от CSRF.
В целом, машинно-сгенерированные диаграммы доставляют проблемы. Всегда окажется, что надо сдвинуть конкретный блок на сантиметр, и без приседаний это невозможно. Или машина производит слишком шумный результат, который трудно читать. Поэтому лучший вариант -- руками.
Замечу, что после JSON RPC к обычному REST уже не хочется возвращаться. В REST данные размазаны по всему запросу: метод, заголовки, параметры пути, query-параметры, тело JSON, тело multipart/form-data и так далее. Весь этот зоопарк утомляет.
Вопрос не мне, но отвечу. GraphQL предлагает больше абстракций: это запросы, изменения и подписки. Плюс ко всему это язык, который нужно парсить. У GraphQL всегда проблема с глубоко вложенными данными, а также проблема N+1, когда первый запрос достает сущности первого порядка, а затем для каждой из них делается запрос на родительские. В целом, я был удивлен тому, сколько обвесов нужно писать вокруг GraphQL, чтобы он работал как надо.
Вдогонку 6) JSON-RPC не обязывает использовать именно JSON. Можно различать формат по заголовку и для веба использовать JSON, а для бека MessagePack, что уменьшит трафик на треть и повысит скорость записи/чтения.
1) Remote Procedure Calls как конценпция разработана не в Google. Уже лет 20 существуют XML-RPC и JSON-RPC со своими спецификациями.
2) как видно из графика, обычный HTTP+Keep-Alive почти не уступает по скорости gRPC. Позволить Keep-Alive себе может каждый.
3) Как справедливо заметили выше, gRPC дорого обходится в вебе. Схема с JSON-RPC + websockets/keep-alive наоборот, работает прозрачно и открыто.
4) любой RPC (JSON, XML, Googe) выигрывает у REST просто за счет того, что есть единая точка входа в API. Не нужно иметь 30 урлов с вариациями GET/PUT/ETC. В RPC достаточно один раз все наладить, а потом расширять определения.
5) Синтаксис: что такое калькулятор это понятно: класс с двумя числами. Но как объяснить эту запись:
```
Calculator calculator = 1
```
мы что, присвоили экземпляру калькулятора единицу?
Вместо итога: gRPC, может быть и хорош, но как правило хватает JSON-RPC + gzip + websocket/keep-alive.
Я вот лично не уверен в этой галочке. Разве в офисе есть таковая, чтобы переключиться на старое меню до появления Ribbon?
Спокойно!
Не совсем понял вопрос. Сделайте апишку `GET /api/me`, которая вернет словарик с полями текущего пользователя по куке.
Что-то вы усложняете. Для авторизации на сайте используется кука с флагами httpOnly, secure, path и другими. В ее подписи участвуют IP и User Agent. Ну и базовая защита от CSRF.
Напомнило клипы IC3PEAK, только без того запала.
В целом, машинно-сгенерированные диаграммы доставляют проблемы. Всегда окажется, что надо сдвинуть конкретный блок на сантиметр, и без приседаний это невозможно. Или машина производит слишком шумный результат, который трудно читать. Поэтому лучший вариант -- руками.
UPD: не заметил bool
Замечу, что после JSON RPC к обычному REST уже не хочется возвращаться. В REST данные размазаны по всему запросу: метод, заголовки, параметры пути, query-параметры, тело JSON, тело multipart/form-data и так далее. Весь этот зоопарк утомляет.
1) Даже если не видит, то что? 2) Вам ли оценивать других?
Вопрос не мне, но отвечу. GraphQL предлагает больше абстракций: это запросы, изменения и подписки. Плюс ко всему это язык, который нужно парсить. У GraphQL всегда проблема с глубоко вложенными данными, а также проблема N+1, когда первый запрос достает сущности первого порядка, а затем для каждой из них делается запрос на родительские. В целом, я был удивлен тому, сколько обвесов нужно писать вокруг GraphQL, чтобы он работал как надо.
Кирилл, взаимно рад! Ясно, всяческих успехов с проектом.
Взялись поучать, а в итоге пассивная агрессия и хамство. Класс.
Это бывший Хекслет? По крайней мере так написано в подвале сейта. Почему переименовали сервис?
Это число просмотров, плюсов или часовая ставка?
Нет, не ладно. Для такой подачи материала есть другие сайты.
Можно попросить автора не писать на Хабр? Спасибо.
Вдогонку 6) JSON-RPC не обязывает использовать именно JSON. Можно различать формат по заголовку и для веба использовать JSON, а для бека MessagePack, что уменьшит трафик на треть и повысит скорость записи/чтения.
Мои пять копеек.
1) Remote Procedure Calls как конценпция разработана не в Google. Уже лет 20 существуют XML-RPC и JSON-RPC со своими спецификациями.
2) как видно из графика, обычный HTTP+Keep-Alive почти не уступает по скорости gRPC. Позволить Keep-Alive себе может каждый.
3) Как справедливо заметили выше, gRPC дорого обходится в вебе. Схема с JSON-RPC + websockets/keep-alive наоборот, работает прозрачно и открыто.
4) любой RPC (JSON, XML, Googe) выигрывает у REST просто за счет того, что есть единая точка входа в API. Не нужно иметь 30 урлов с вариациями GET/PUT/ETC. В RPC достаточно один раз все наладить, а потом расширять определения.
5) Синтаксис: что такое калькулятор это понятно: класс с двумя числами. Но как объяснить эту запись:
```
Calculator calculator = 1
```
мы что, присвоили экземпляру калькулятора единицу?
Вместо итога: gRPC, может быть и хорош, но как правило хватает JSON-RPC + gzip + websocket/keep-alive.
Когда он был у руля фирмы, то и выдавал с командой игры, изменившие индустрию. А теперь над ним, поди, сто эффективных менеджеров.
Что здесь "красиво ужасного"? Обычный лисп.