что значит выстрелить, давно и успешно используется

2. я так понимаю вопрос про jsonrpc over http
со стороны сервра: сервис обычно спрятан за каким-нибудь nginx, который умеет HTTP 1.1, если напрямую, например, в локалке, зависит от ЯП или фреймворка, но обычно проблем с этим нет
со стороны клиента: строится так же на базе уже готового http клиента, который умеет HTTP 1.1

xml слишком многословен и затратен при кодировании/декодировании

Будет что-то типа Api.LikePost, Api.BookmarkPost, Api.SharePost.
В jsonrpc нет путей, есть нотация Service.Method. На одном эндпоинте может быть несколько сервисов.

Yet another standart, или еще один способ отказаться от простых и понятных систем мониторинга.
Меня это постоянно удивляет. Если уж используется HTTP для транспорта, то почему он используется специально целенаправленно в обрезанном виде? Invalid Request с ответом 200.

потому что HTTP для jsonrpc yet another transport

О да, операторы драв и лине ))

Во-вторых, кодов ответа в HTTP всегда меньше, чем типов ошибок бизнес-логики, которые вы бы хотели возвращать на клиент.
Кто-то всегда возвращает 200-ку, кто-то ломает голову, пытаясь сопоставить ошибки с HTTP-кодами.
В JSON-RPC весь диапазон integer — ваш.

наверное, опять холиварная тема, но в некоторых случаях предпочел оставить поле error для ошибок протокола, описанных в спецификации, а ошибки бизнес логики передавать внутри result. Некоторые случаи — это api для межсервисного взаимодействия, где сервис одновременно может поддерживать jsonrpc, grpc, очереди сообщений и не только… хочется минимизировать влияние протокола на форматы сообщейни.

внутри это +1 операция чтения, чтобы понять а есть там что-то или нет, если не конец, то надо сохранить результат упреждающего чтения а соответственно при очередном вызове проверять было ли что-то прочитано заранее…
сомнительное такое преимущество

> Завтра сделают биндинг к нему для Go — и всё, тема статьи снова станет неактуальной.
биндингом не решится, в go свой рантайм и вызов сишных функций дороже нативных.
Только так ли это нужно, если на не свежем i5-4670 net/http из стандартной библиотеки go 1.11 выдает 160k rps.

это чисто вебсокетная либа

понятно, что автор унаследовал название от плюсовой либы, но все равно как странно называть WebSokets реализацию http-сервера, пусть и с web-socket на борту

О, вьюсоник!
в 2001м подрабатывал в универе, в хозяйстве был 17" вьюсоник про серии с плоским экраном. это был космос по сравнению с основной массой 14" пузатиков

хм, мне показалось что фраза про 28 запросов на купон относилась к питонячей версии

ps
а насколько много в бд оперативных данных? можно ли все загрузить в рам и в бд лазить только на запись?

Мы пошли по второму пути, закэшировав некоторые результаты запросов в памяти приложения

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

был и eAccelerator и APC
сейчас это уже в ядре

Устройтесь в баду и перепишите, делов то ))

Исключительная, от того и зафиксить надо как можно быстрее.

Альтернативные способы доставки это хорошо, но вот то, что один из каналов не является самодостаточным мне видится недостатком. Если такое скрыто за бекендом — норм, если если же клиенту для получения актуальных данных надо сначала слазить в два места по двум разным протоколам — странно с т.з архитектуры.
все имхо

ps
rpiontik, это используется только вашим клиентом или сторонними клиентами тоже?

у меня вопрос, как вы отображаете цену на графике? с фиксированной точностью или на клиенте уже есть информация о точности цены конкретного инструмента?

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

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