Совместное первое совместное веб-приложение в реальном времени - PullRequest
0 голосов
/ 03 января 2019

В настоящее время у меня есть приложение Electron ReactJS, которое использует CouchDB в качестве бэкэнда для синхронизации и обновления в реальном времени. Мне было поручено «портировать» серверную часть этого приложения на существующий веб-сервер. Цель состоит в том, чтобы использовать существующие реализации управления разрешениями и бизнес-логики. В то же время цель состоит в том, чтобы провести рефакторинг структур данных, так как данные сильно реляционны по своей природе. Тем не менее, лично я бы оставил приложение на CouchDB, так как оно полностью удовлетворяет основным требованиям «в автономном режиме и в режиме реального времени», и просто добавил недостающие уровни аутентификации и разрешений, но руководство хочет иного.

Порт будет использовать существующий веб-сервер (работает под управлением Play Framework с Scala) и реляционную базу данных (MySQL). Я копался в Интернете для хорошего существующего решения. «Простое» решение, которое пришло мне в голову, звучит скучно и будто я заново изобретаю колесо. Моя идея состояла в том, чтобы создать API и, кроме того, отправлять обновления в реальном времени пользователям, для которых изменение имеет значение, через веб-сокеты. Для управления состоянием на клиенте я бы использовал Redux + Redux Offline. Хотя это будет работать, для этого потребуется много ручного подключения CRUD на внутреннем сервере и соответствующих запросов и мутаций на клиенте.

Я посмотрел на AWS AppSync, Meteor.js и Apollo. AWS AppSync звучит как то, что я мог бы использовать, но он полагается на доступность для него базы данных, что невозможно, поскольку мой экземпляр БД находится в помещении. От Apollo клиентская часть звучит как вариант, с которым я мог бы пойти, а затем использовать Sangria на бэкэнде. Я полагаю, что я мог бы также отбросить идею Redux и использовать «локальное состояние» Аполлона, хотя это требует больше размышлений, поскольку я не знаком с ним.

Все последние решения включают GraphQL. Хотя для бэкэнда это все равно потребует некоторой работы, само взаимодействие между фронтэндом и бэкэндом будет проще в обработке.

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

...