Конкретные вопросы о gunDB как автономной БД для проекта Cordova

Я только что узнал о gunDB, и концепция кажется очень интересной, и я хотел бы узнать больше об этом, прежде чем начинать оценивать ее дальше.

  • Если бы я хотел создать чат-приложение, например, учебник, но реализовать чат комнаты. Будет ли у клиентов возможность "подписываться" только на определенные чаты и избегать передачи содержимого каждой другой комнаты чата? Как это влияет на сохранение, если не все данные синхронизируются со всеми клиентами? Нужно ли запускать специальный клиент (т.е. Сервер?), Который будет обеспечивать постоянную сохранность всех данных?
  • В этом же учебнике для чатов, если я хочу подписаться на несколько чатов, мне нужно создать несколько экземпляров Gun, причем каждый из них использует "одноранговое" хранилище?
  • Как управлять пользователями/паролями и т.д. в gunDB? Отправляя каждому клиенту копию пользовательской БД, интересно из точка репликации, но с точки зрения безопасности, кажется, счетчик интуитивным.
  • Есть ли способ попросить пистолет только синхронизировать при определенных обстоятельствах, например, когда доступно WiFi-соединение (подумайте о Кордове)?
  • Что относительно временных данных? Есть ли способ в приложении чата, для экземпляр, чтобы сообщить gunDB, что меня интересуют только будущие сообщения и игнорировать все, что было создано до определенного state/timestamp (снова, чтобы избежать передачи огромного количества данных по дорогостоящий план данных)?
  • Как вы сохраняете данные на диске (потенциально круговые) в gunDB и загружать данные обратно в БД при необходимости?
  • Можете ли вы попросить пистолет контролировать два ключа одновременно? Например, если клиенту нужно отображать данные чата и список todo (оба "ключа" из учебника), предполагая, что оба "заглядывают".
  • Есть ли учебник по использованию моего собственного сервера для хранения?

ОТВЕТЫ

Ответ 1

  • Чаты. Таким образом, чат-учебник загрузил таблицу чата, вы можете просто иметь "комнаты". Тогда вы можете захватить только комнату, которую вы хотите. Поскольку gun использует partials, чтобы быть быстрым, это приведет только к загрузке данных, на которые вы подписаны. Да, клиенты могут хранить только подмножество данных в целом, но это, конечно, может повлиять на уровни репликации/сохранения. Если вы беспокоитесь об этом, то запуск "сильного" партнера (например, сервера) - это простое и идеальное решение, так как оно будет поддерживать все. (И, к сожалению, поскольку у WebRTC есть проблемы *, вам как-то придется запускать peer-сервер ретранслятора в любом случае. Так что также можно использовать его для хранения.)

  • Несколько экземпляров. Вам не нужно создавать экземпляры нескольких пистолетов на ключ. На самом деле это плохо. Лучше, если вы этого не сделаете. Возможно, однако мы не тестировали это столько, сколько должны, потому что это не идеально.

  • Безопасность/авторизация - очень трогательная тема, так что это зависит от того, как вы хотите создать свое приложение. Если вы собираетесь создать настоящий P2P/децентрализованный дизайн, вам нужно будет сделать криптографию и подписи с закрытым/закрытым ключом . Таким образом, другие пользователи не могут действительно читать данные, даже если они могут помочь в резервном копировании данных. Однако, если вы хотите, чтобы все упрощалось и создавалось ваше приложение, так как большинство приложений построено... как централизованная служба, тогда вы прокси-сервер записываете на свой сервер. Это тот же самый метод, который большинство людей использует в настоящее время при создании приложений, а GUN может делать то же самое.

  • Данные о скорости передачи WiFi/скорости. К сожалению, это недоступно в JavaScript, но похоже, что такие гибридные приложения, как вы упомянули в PhoneGap, могут получить доступ к этой информации. GUN предназначен для работы в таких сценариях, поскольку он не работает в режиме онлайн. Но как вы взаимодействуете с внешними API-интерфейсами, которые предоставляют вам эти условия... не соответствует моему опыту, но выполнимо.

  • Временные данные/ограничение передачи данных. Сначала см. Мой ответ, выполнимый, но зависящий от внешних API. С точки зрения ограничения запросов, да, да. A: Мы скоро представим "лексические курсоры", которые позволят клиентам сдерживать ответы, однако мы, вероятно, будем постепенно наращивать каждую из своих возможностей ограничений (поскольку это не было огромным приоритетом для сообщества, но ваше участие будет эскалировать его!), сначала с точными совпадениями свойств (думаю, как оператор выбора SQL), на самом деле это то, что мы будем использовать для создания расширения запроса SQL для пушки!), затем второй лексический диапазон (выберите свойства, начинающиеся с 'a' через 'c'), который может быть выполнен с диапазонами временных меток, затем третий байт-ограничение (например, только отправьте обратно не более 200 байт за раз). Тем не менее, очевидная вещь, которую вы можете сделать самостоятельно (не то, что вы хотите), вы могли бы просто иметь столик комнат, а затем комната представляет собой таблицу кусков, а куски - это таблица сообщений. Потенциально с комнатой, имеющей "последний" фрагмент, вы можете легко получить доступ к своему чат-приложению, выполнив gun.get('rooms').path('mychatroom').path('last').map().val(function(message){ console.log(message); }); или что-то в этом роде. Это позволит вам точно контролировать условия, которые вы хотите, но также означает, что вам нужно сделать немного больше работы.

  • Циркулярные ссылки. Для вас уже есть столько круговых ссылок, сколько вы хотите - это то, где пистолет превосходит из-за его структуры графика (круговые ссылки, таблицы, документы, ключ/значение, что угодно).

  • Да, пистолет может одновременно контролировать несколько клавиш.

  • Использование собственного сервера для хранения... это может означать пару разных вещей. Как запустить собственный пушечный сервер? Для этого есть простая оболочка: https://www.npmjs.com/package/gun-server. Если вам нужны примеры с Express, и все это просто. Как использовать текущую развернутую файловую систему сервера как хранилище, потому что вы не хотите использовать S3? Вы можете использовать драйвер уровня https://github.com/PsychoLlama/gun-level. Это ответ?

* WebRTC требует, чтобы серверы STUN/ICE/сигнальные серверы загружали соединение WebRTC. Это очень раздражает. Это означает, что даже если WebRTC является P2P, для того, чтобы подключиться, вам нужно пройти через какой-либо сервер, и это должно радоваться за каждую загрузку страницы. Из-за этого мы по умолчанию пушка пушки с websockets/JSONP, что она должна подключаться к peer-серверу ретранслятора пистолета (есть также аналогичные ретрансляторы для сообществ, которые люди могут использовать для личных экспериментов, но легко управлять своими силами, в пункте 4). В результате мы еще не выпустили адаптер WebRTC, несмотря на то, что пистолет WebRTC + идеально подходит - глупые серверы STUN/ICE/сигнализации.