В рейтинге участвует:

групп: 1613

каналов: 2412

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

Архитектура ИТ-решений

2774 membersпожаловаться на группу
2020 December 08

A

Alex in Архитектура ИТ-решений
Хотя может и правда (sic!) имеется ввиду мобильное приложение и пользователь, который раньше делал два жеста в минуту, а теперь делает двадцать жестов  в минуту и приложение не крашится
источник
15:34пожаловаться#1

PD

Phil Delgyado in Архитектура ИТ-решений
Но вообще, конечно, в архитектуре взаимодействия мобилки и бэка много о чем можно поговорить.
Например про асинхронные запросы и обмен через web-socket вместо всего всякого REST...
Правда, описывать этот API сложно...
источник
15:35пожаловаться#2

A

Alex in Архитектура ИТ-решений
ладно, пообсуждали кликбейт заголовок и хватит
источник
15:37пожаловаться#3

p

pragus in Архитектура ИТ-решений
Phil Delgyado
Но вообще, конечно, в архитектуре взаимодействия мобилки и бэка много о чем можно поговорить.
Например про асинхронные запросы и обмен через web-socket вместо всего всякого REST...
Правда, описывать этот API сложно...
а чего сложного описывать? какой-нибудь json-rpc или grpc
источник
15:48пожаловаться#4

PD

Phil Delgyado in Архитектура ИТ-решений
Ну, это не swagger..
И, конечно же, не json-rpc и не grpc, это именно про честную асинхронщину на сообщениях
Типа "отправил запрос на историю операций", в ответ в канал (web-socket) приходят (когда придется) отдельные страницы или блоки.
источник
15:50пожаловаться#5

p

pragus in Архитектура ИТ-решений
Phil Delgyado
Ну, это не swagger..
И, конечно же, не json-rpc и не grpc, это именно про честную асинхронщину на сообщениях
Типа "отправил запрос на историю операций", в ответ в канал (web-socket) приходят (когда придется) отдельные страницы или блоки.
> "отправил запрос на историю операций", в ответ в канал

стриминг в grpc есть, причём даже дуплекс
источник
15:56пожаловаться#6

PD

Phil Delgyado in Архитектура ИТ-решений
grpc не всегда стоит использовать, если не контролируешь инфраструктуру. А то там будет балансер, который его не поддерживает - и опаньки.
источник
15:58пожаловаться#7

PD

Phil Delgyado in Архитектура ИТ-решений
Ну и мне не стриминг интересен, а события.
источник
15:59пожаловаться#8

PD

Phil Delgyado in Архитектура ИТ-решений
и категорически не интересен gprc
источник
15:59пожаловаться#9

p

pragus in Архитектура ИТ-решений
Phil Delgyado
grpc не всегда стоит использовать, если не контролируешь инфраструктуру. А то там будет балансер, который его не поддерживает - и опаньки.
но ws приводит к аналогичной картине и проблемам балансировки.
источник
16:11пожаловаться#10

PD

Phil Delgyado in Архитектура ИТ-решений
Ну, там я легко это могу сам делать, если нужно. Впрочем, в grpc тоже.
Хм, я подумаю, можем ли мы завязаться на http/2 и как поток событий сделать на grpc
источник
17:23пожаловаться#11

PD

Phil Delgyado in Архитектура ИТ-решений
Хотя пилить кодогенераторы не хочется, конечно
источник
17:32пожаловаться#12
2020 December 09

p

pragus in Архитектура ИТ-решений
Phil Delgyado
Ну, там я легко это могу сам делать, если нужно. Впрочем, в grpc тоже.
Хм, я подумаю, можем ли мы завязаться на http/2 и как поток событий сделать на grpc
1. В случае что с grpc, что с ws балансер должен уметь разбирать payload.
2. Стриминг в grpc, насколько я помню, это как раз "сделать запрос и получить итератор, который возвращает сообщения".
3. Вся эта машинерия уже работает поверх стримов в http/2
4. ws поверх http/2 относительно недавно стандартизовали и не так уж много его реализаций
источник
00:43пожаловаться#13

p

pragus in Архитектура ИТ-решений
Из интересного - в grpc можно использовать flatbuffers вместо protobuf
источник
00:44пожаловаться#14

PD

Phil Delgyado in Архитектура ИТ-решений
1. Э, а зачем payload разбирать на балансере, поясни?
2. Вот я пытаюсь понять, как это будет работать при сбоях сети, например.Кто восстановит соединение и получит остатки по итератору.
5. Ну и как-бы обойтись без кодогенерации и protobuf (которые ужасны)
источник
00:46пожаловаться#15

p

pragus in Архитектура ИТ-решений
Phil Delgyado
1. Э, а зачем payload разбирать на балансере, поясни?
2. Вот я пытаюсь понять, как это будет работать при сбоях сети, например.Кто восстановит соединение и получит остатки по итератору.
5. Ну и как-бы обойтись без кодогенерации и protobuf (которые ужасны)
А как балансировать не пойми что?
источник
00:59пожаловаться#16

PD

Phil Delgyado in Архитектура ИТ-решений
Ну, вообще-то достаточно только заголовков, а обычно и только url
Внутрь зачем лезть?
источник
01:00пожаловаться#17

PD

Phil Delgyado in Архитектура ИТ-решений
Балансировку можно делать еще до терминирования tls...
источник
01:00пожаловаться#18

p

pragus in Архитектура ИТ-решений
Phil Delgyado
Балансировку можно делать еще до терминирования tls...
Соединения в http2 персистентны, т.е. первый же вызов api example.com поднимет Коннект и все остальные запросы будут его переиспользовать.

Да и с чистым ws будет аналогично, ведь обычно хочется rpc балансировать  per call, а не per connection
источник
01:28пожаловаться#19

PD

Phil Delgyado in Архитектура ИТ-решений
pragus
Соединения в http2 персистентны, т.е. первый же вызов api example.com поднимет Коннект и все остальные запросы будут его переиспользовать.

Да и с чистым ws будет аналогично, ведь обычно хочется rpc балансировать  per call, а не per connection
Кто его перевосстанавливает (клиент заехал на машине в туннель) при разрыве?
источник
01:29пожаловаться#20