а вы про какой софт?
для клиентского это не критично, а для серверного вполне может быть узким местом.
Например, для API Gateway это критично. Это критично для сервиса, который оперирует данными в памяти.
2. я так понимаю вопрос про jsonrpc over http
со стороны сервра: сервис обычно спрятан за каким-нибудь nginx, который умеет HTTP 1.1, если напрямую, например, в локалке, зависит от ЯП или фреймворка, но обычно проблем с этим нет
со стороны клиента: строится так же на базе уже готового http клиента, который умеет HTTP 1.1
Будет что-то типа Api.LikePost, Api.BookmarkPost, Api.SharePost.
В jsonrpc нет путей, есть нотация Service.Method. На одном эндпоинте может быть несколько сервисов.
Yet another standart, или еще один способ отказаться от простых и понятных систем мониторинга.
Меня это постоянно удивляет. Если уж используется HTTP для транспорта, то почему он используется специально целенаправленно в обрезанном виде? Invalid Request с ответом 200.
Во-вторых, кодов ответа в 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" пузатиков
Исключительная, от того и зафиксить надо как можно быстрее.
Альтернативные способы доставки это хорошо, но вот то, что один из каналов не является самодостаточным мне видится недостатком. Если такое скрыто за бекендом — норм, если если же клиенту для получения актуальных данных надо сначала слазить в два места по двум разным протоколам — странно с т.з архитектуры.
все имхо
ps
rpiontik, это используется только вашим клиентом или сторонними клиентами тоже?
у меня вопрос, как вы отображаете цену на графике? с фиксированной точностью или на клиенте уже есть информация о точности цены конкретного инструмента?
для клиентского это не критично, а для серверного вполне может быть узким местом.
Например, для API Gateway это критично. Это критично для сервиса, который оперирует данными в памяти.
со стороны сервра: сервис обычно спрятан за каким-нибудь nginx, который умеет HTTP 1.1, если напрямую, например, в локалке, зависит от ЯП или фреймворка, но обычно проблем с этим нет
со стороны клиента: строится так же на базе уже готового http клиента, который умеет HTTP 1.1
В jsonrpc нет путей, есть нотация Service.Method. На одном эндпоинте может быть несколько сервисов.
потому что HTTP для jsonrpc yet another transport
наверное, опять холиварная тема, но в некоторых случаях предпочел оставить поле error для ошибок протокола, описанных в спецификации, а ошибки бизнес логики передавать внутри result. Некоторые случаи — это api для межсервисного взаимодействия, где сервис одновременно может поддерживать jsonrpc, grpc, очереди сообщений и не только… хочется минимизировать влияние протокола на форматы сообщейни.
сомнительное такое преимущество
биндингом не решится, в go свой рантайм и вызов сишных функций дороже нативных.
Только так ли это нужно, если на не свежем i5-4670 net/http из стандартной библиотеки go 1.11 выдает 160k rps.
в 2001м подрабатывал в универе, в хозяйстве был 17" вьюсоник про серии с плоским экраном. это был космос по сравнению с основной массой 14" пузатиков
ps
а насколько много в бд оперативных данных? можно ли все загрузить в рам и в бд лазить только на запись?
почему это не было сделано раньше?
кеширование выборок это первое что приходит в голову, когда бд становится узким местом
сейчас это уже в ядре
Альтернативные способы доставки это хорошо, но вот то, что один из каналов не является самодостаточным мне видится недостатком. Если такое скрыто за бекендом — норм, если если же клиенту для получения актуальных данных надо сначала слазить в два места по двум разным протоколам — странно с т.з архитектуры.
все имхо
ps
rpiontik, это используется только вашим клиентом или сторонними клиентами тоже?