Архитектура подписки сервера приложений и сервера разбора - PullRequest
0 голосов
/ 02 ноября 2018

У меня есть общий вопрос об архитектуре. У меня есть приложение с 4 компонентами:

  • Веб-приложение
  • Мобильное приложение (iOS и Android)
  • Сервер приложений
  • Сервер разбора

Поток данных, который я установил прямо сейчас: клиент (веб или мобильный) выполняет API-вызов к серверу приложений -> сервер приложений вызывает Parse Server -> анализирует сервер передает данные на сервер приложений -> сервер приложений передает данные обратно в клиент.

Поскольку требования включают в себя функциональность push-уведомлений, которая поддерживается Live Queries сервера Parse (https://docs.parseplatform.org/parse-server/guide/#live-queries), Я хотел бы использовать это, но не уверен, как она будет вписываться в текущую модель, которая у меня есть) .

С точки зрения передового опыта или стандартного использования, это правильный подход, чтобы сервер приложений «подписывался» на Parse Server, а затем клиент использовал некоторый тип подписки на сервер приложений, чтобы разрешить передачу данных с сервера. Parse Server -> Сервер приложений -> Клиент? Этот подход кажется хорошим, потому что он сохраняет тот же поток, хотя кажется, что он добавляет много сложности.

Другой вариант, о котором я думал, - это разрешить Клиенту «подписаться» непосредственно на Parse Server, что потребовало бы дополнительного шага, но добавило бы дополнительный поток: это практика обратно, чтобы направлять некоторые API звонки с Клиента -> Сервер приложений -> Сервер Parse и некоторые другие (подписки) с Клиента -> Сервер Parse?

Есть ли у кого-нибудь понимание того, как лучше всего справиться с ситуацией, или о типичных способах построения такого типа решения.

Надеюсь, этот вопрос имеет смысл. Мы все еще находимся на этапе архитектурного проектирования, и я пытаюсь обдумать наилучший подход.

...