Будет ли RP C работать как постоянное соединение для двунаправленных событий? - PullRequest
0 голосов
/ 12 января 2020

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

У меня есть мобильное приложение, которое в настоящее время работает с различными конечными точками REST CRUD. Некоторые из этих конечных точек выполняют некоторые длительные задачи, и мобильные приложения опрашивают после истечения времени ожидания, чтобы увидеть, была ли задача завершена. Есть событие, которое сбрасывается в поток Kinesis, когда это действие выполнено, поэтому я мог бы запустить опрос в этой точке вместо слепого ожидания. Эти приложения также должны начинать отправку различных событий (в основном аналитических) непосредственно на мой сервер, а не стороннему поставщику (Firebase). Я хочу поставить ПО C, чтобы посмотреть, как можно сложить некоторые из этих функций, и хотел бы получить представление о моем подходе, прежде чем я сожгу пару часов.

Первая мысль: Websockets. Я использовал их раньше и знаю, что могу отправлять аналитику через веб-сокет, а также слушать поток Kinesis, чтобы отправить событие обратно в приложение, которое завершило задачу. Каждое WS-соединение может быть помечено с помощью userId (который доступен в потоке Kinesis), так что это будет просто цикл по каждому из них и отправка его клиенту с соответствующим ID. Затем этот клиент может опросить, когда он в хорошем состоянии. Для масштабирования я мог бы просто поставить другой сервер WS после насыщения первого и go по горизонтали.

Вторая мысль: RP C. Я новичок в RP C, но небольшое количество, которое я использовал, мне действительно нравится. Я знаю, что могу использовать двунаправленную связь, используя их, но для достижения того же результата мне нужно, чтобы сервер RP C ждал завершения длинной задачи, уведомлялся службой, выполняющей задачу, а затем уведомлял обратно клиенту? Учитывая то, как я настраивал RP C в прошлом, я не уверен, смогу ли я заставить его слушать поток и действовать на тех же данных, что и веб-сокет. Кроме того, я не уверен, что использование RP C таким способом приведет к тому, что тысячи подключений к серверу RP C будут прослушивать поток и фильтровать все сообщения, просто чтобы получить сообщения с идентификатором для своего текущего клиента (это кажется очень неэффективным).

Актуальный вопрос: Учитывая, что мне нужно отправлять и получать данные с сервера в режиме реального времени, но данные, получаемые обратно, напрямую не получены из данных, отправленных на сервер, RP C или веб-розетка лучший первый подход? Другие сервисы, с которыми взаимодействует, кроме RPC / Websocket, в настоящее время все REST.

...