Замечу, что после 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.
Мне кажется, это и так очевидно, что клавиатур долгое наследние. Переделывать стандарт экономически трудно. Это подверждает тот факт, что половина стартапов с новыми клавиатурами не проходит Какстартер, а наладить хоть какой-то выпуск удается единицам. Хорошие клавиатуры серии Скульпт выпустили Микрософт. Я лично пользуюсь внешней клавиатурой Эпла.
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.
Когда он был у руля фирмы, то и выдавал с командой игры, изменившие индустрию. А теперь над ним, поди, сто эффективных менеджеров.
Что здесь "красиво ужасного"? Обычный лисп.
Мне кажется, это и так очевидно, что клавиатур долгое наследние. Переделывать стандарт экономически трудно. Это подверждает тот факт, что половина стартапов с новыми клавиатурами не проходит Какстартер, а наладить хоть какой-то выпуск удается единицам. Хорошие клавиатуры серии Скульпт выпустили Микрософт. Я лично пользуюсь внешней клавиатурой Эпла.
Зачем писать про историю клавиатур под заголовком "Почему я отказался от стандартной клавиатуры"? Вы даже на свой вопрос не ответили.
37 баллов: boobs, tits, ass, etc...
Потому что и вирусов нет. Будут -- напишут антивирус.
извините, как язык может быть буржуазным?
Очень жаль, что у компаний нет кармы. Иначе ее бы быстро спустили в минуса за подобный треш.