2015-04-24 4 views
4

Мой проект можно разделить на 3 компонента: настольное приложение, серверный сервер, интерфейс сервера. Я использую websockets-backend и backend-frontend-связь. Frontend - одностраничное приложение. Целые выглядит следующим образом:Связь между настольным приложением и веб-интерфейсом

application-backend and backend-frontend communication

Мне нужно реализовать обмен данными между веб-интерфейсе и приложения (пунктирная стрелка на рисунке выше). Я могу использовать сервер backend как прокси-сервер, но было бы более полезно иметь прямую связь между интерфейсом и приложением, так что бэкэнд-ресурсы не будут потрачены впустую.

Есть ли способ установить прямую связь между локальным приложением и веб-интерфейсом?

PS: Я использую Go для обоих бэкэнд и приложений, JavaScript для интерфейсов и WebSockets для связи, но общие ответы на архитектуру приветствуются.

+3

Что означает «интерфейс сервера» в этой ситуации? Вы говорите о чем-то, запущенном в браузере на том же амхине, что и «настольное приложение»? – JimB

+0

«Тот же сценарий кресла» (браузер и приложение на том же компьютере) будет охватывать большинство случаев, но не все из них. Любое предложение приветствуется. – Ondra

+0

Бэкэнд-ресурсы не пропадают впустую - какие важные бэкэнд-ресурсы делают, кроме выполнения запросов вашего интерфейса? – Guanxi

ответ

3

Вы пытаетесь подключиться к JavaScript Frontend из своего настольного приложения? Если да, я могу подумать о следующих вариантах:

  1. WebRTC. Он поддерживается Chrome (и Opera) и Firefox.
  2. Chrome Native Messaging, это работает только для Chrome, отправляет/получает информацию от stdin/out вашего рабочего стола.

В целом я думаю, что WebRTC может быть лучшим решением. Оба решения требуют, чтобы вы запускали свой веб-интерфейс в современном браузере, хотя Chrome/Firefox.

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

+0

Меня особенно интересует последнее решение. Я могу сделать локальный сервер в настольном приложении и позаботиться о безопасности, но я думаю, что у меня часто будут проблемы с некоторыми брандмауэрами ... Просто любопытно, как часто вы думаете, что у меня будут такие проблемы? И как я могу их решить? – Ondra

+1

Если вы подключаетесь к локальному хосту, брандмауэры обычно не слишком беспокоятся об этом, однако в этом случае вам нужно будет также решить проблемы с перекрестными доменами: если ваше приложение работает на http: // www. domain.com, а затем подключение к http: // localhost будет считаться перекрестным доменом. JSONP решает эту проблему. Однако, если вы используете https, это станет невозможным, поскольку вы не сможете выдавать сертификат на localhost. Вот почему я не упомянул этот метод как один из пунктов пули, потому что на самом деле это хак, а не решение. –

+0

@QianQiao WebRTC было бы неплохо, но быстрый поиск Google не заставил клиента Go WebRTC. Я что-то не замечаю, или вы предлагаете ему делать WebRTC с нуля? Я полагаю, что нетривиально реализовать клиент WebRTC. –

1

Это может сработать, но может занять совсем немного дополнительной мысли сделать надежно:

Есть на рабочем столе программы запуска сервера веб (гнездо) на некотором произвольном порту р, а затем попытаться поговорить на локальный : p с вашего интерфейса.

Или вы можете попробовать сделать WebRTC между браузером и настольным приложением. Быстрый поиск оказался https://github.com/coreos/go-webrtc-datachannel, который является всего лишь документом планирования на данный момент.

Смежные вопросы