Какие уровни абстракции типичны для клиентов и серверов в шаблоне запрос / ответ?

Question

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

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

Итак, вместо того, чтобы иметь что-то вроде этого:

Клиент <-> Сервер

Вы бы получили:

Клиент <-> Посредник <-> Сервер

Где посредником будет сверхлегкая служба, способная быстро отправлять запросы от клиента. По сути, это будет сортировать запросы кэш-памяти к серверу, и если состояние действительно изменится на сервере, сервер уведомит посредника, и в будущих запросах посредник ответит обновленными данными.

Итак, к моему актуальному вопросу. Мой актуальный вопрос: есть ли название для этого шаблона, и является ли он относительно распространенным (или необычным)? Существуют ли сервисы или примеры, где реализовано нечто подобное? Существуют ли службы, которые помогают внедрить такой шаблон? Например, я потратил немного времени на исследование ZeroMQ, но, похоже, он использовался просто для передачи сообщений, и у службы нет возможности кэшировать данные или иным образом управлять состоянием посредника, как я предполагаю.

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

Answer 1

Я вижу это как ClientProxy.

Концептуально вы действительно хотите, чтобы Сервер что-то говорил Клиентам, но по какой-то причине вы не можете доставить эти события Клиенту. Поэтому вместо этого вы создаете прокси-сервер, которому сервер отправляет события. Затем ClientProxy и реальный клиент общаются друг с другом по-своему, в данном случае путем опроса.

Попутно обратите внимание, что есть такие технологии, как Comet, которые позволяют клиентам браузера получать push-события.

Answer 2

В предложенной вами архитектуре это звучит так: «Посредник» - это просто кэш данных.Когда Сервер обнаруживает обновления данных, он связывается с Посредником, чтобы обновить свои кэшированные данные.Клиенты связываются с Посредником, который может быстро ответить кэшированными ответами.

Если вышеприведенное предположение верно, почему бы просто не научить Сервер кешировать данные?Таким образом, он будет быстро реагировать (возвращать кэшированные данные) всякий раз, когда клиент запрашивает их.И когда данные обновляются, они могут мгновенно аннулировать свой собственный кеш.Похоже, что это было бы гораздо более легко реализуемым и поддерживаемым решением.

Есть ли причины, по которым вам нужен посредник, чтобы быть его собственным отдельным и отличным объектом?

Answer 3

Я думаю, что это просто называется архитектура клиент / сервер. Хотя предложение. Вместо того, чтобы использовать этот «промежуточный сервер» между клиентом и сервером, почему бы просто не транслировать сервер всем подключенным клиентам, когда доступно обновление? Таким образом, ваши клиенты не будут постоянно спрашивать ваш сервер, если что-то изменилось.