Архитектура приложения при использовании CouchDB/PouchDB

Мне интересно, как должна выглядеть архитектура при использовании PouchDB в качестве локального хранилища в мобильном приложении вместо localStorage.

На данный момент я привык кэшировать данные своего приложения в localStorage, и при необходимости я выполняю вызов API к серверной части для запроса или отправки данных. Бэкэнд держит всю логику. Такие как:

  • Имеет ли этот пользователь правильное разрешение/роль для выполнения этого действия?
  • Любая другая логика, необходимая для проверки возможности выполнения действия

Затем все данные сохраняются в реляционной базе данных. Сейчас я читаю о базах данных NoSQL и, в частности, о CouchDB и PouchDB. Поэтому мне интересно, как будет выглядеть эта архитектура? В этот момент у меня возникают три вопроса:

  1. Если у меня есть несколько пользователей с собственной аутентификацией, как я могу убедиться, что пользователи получают доступ только к своим данным? И будет ли у меня по-прежнему 1 база данных на сервере?
  2. PouchDB на стороне клиента может синхронизироваться с удаленным PouchDB. Но когда приложение создается с помощью Javascript, как убедиться, что люди не вставляют данные в PouchDB, «взламывая» клиентский Javascript?
  3. Исчезнет ли использование серверной части в таких установках? И если вы хотите иметь API для 3rd party, вы просто помещаете, например, бэкэнд Sails.js вокруг CouchDB?

cordova ionic-framework sails.js couchdb pouchdb
person Mark Veenstra    schedule 10.06.2015    source источник

Ответы (2)


arrow_upward
10
arrow_downward

Сопровождающий PouchDB здесь, рад ответить на ваши вопросы. :)

Если у меня есть несколько пользователей с собственной аутентификацией, как я могу убедиться, что пользователи получают доступ только к своим данным? И будет ли у меня по-прежнему 1 база данных на сервере?

Руководство есть в README для проверки подлинности pouchdb. Cloudant и Couchbase также имеют собственные системы управления пользователями.

PouchDB на стороне клиента может синхронизироваться с удаленной PouchDB. Но когда приложение создано с помощью Javascript, как убедиться, что люди не вставляют данные в PouchDB, «взламывая» клиентский Javascript?

Вы пишете функцию validate_doc_update на стороне сервера. Когда PouchDB пытается синхронизироваться с CouchDB, любые неудавшиеся документы будут генерировать событие 'denied', и эти документы не будут синхронизироваться.

Что касается локальной базы данных, вы не можете запретить пользователям записывать неверные данные (они всегда могут открыть консоль и делать все, что захотят), но вы можете использовать что-то вроде pouchdb-validation, чтобы повторно использовать функцию проверки на стороне клиента. Или вы можете просто сделать это самостоятельно, когда будете put() документировать.

Исчезнет ли использование серверной части в таких установках? И если вы хотите иметь API для третьей стороны, вы просто помещаете, например, бэкэнд Sails.js вокруг CouchDB?

Некоторые люди пишут приложения PouchDB без какой-либо серверной части (используя только CouchDB/Cloudant/Couchbase), в то время как другим нравится смешивать базу данных с серверной архитектурой по своему выбору. Тебе решать. :)

Одним из интересных решений, если вы используете Express, является использование express-pouchdb, так что вы можете открыть Серверная конечная точка PouchDB внутри существующей архитектуры. Однако для Sails.js вам придется написать свой собственный.

person nlawson    schedule 10.06.2015

arrow_upward
1
arrow_downward

PouchDB на стороне клиента может синхронизироваться с удаленной PouchDB. Но когда приложение создано с помощью Javascript, как убедиться, что люди не вставляют данные в PouchDB, «взламывая» клиентский Javascript?

Чтобы уменьшить риск, вы можете удалить/переопределить глобальную переменную window.PouchDB. Итак, когда ваш код запускается (при условии, что он выполняется внутри замыкания), он может сделать следующее:

function(){
    // your closure
    var PouchDB = window.PouchDB;
    window.PouchDB = null;
    Object.freeze(window);
}

Теперь PouchDB виден внутри закрытия, но не виден из консоли.

Последняя строка замораживает весь объект window, поэтому код не может добавлять какие-либо глобальные переменные после выполнения замораживания. Вы должны вызвать Object.freeze(window) после того, как все ваши библиотеки будут получены и инициализированы. Обратите внимание, что этот трюк может вызвать множество побочных эффектов, поэтому тщательно тестируйте свой код.

Object.freeze гарантирует, что пользователь не сможет скопировать/вставить исходный код PouchDB в консоль и запустить его, но не гарантирует, что пользователь не сможет получить доступ к базовому хранилищу (IDB/WebSQL) напрямую или с помощью вкладки «Ресурсы» консоли.

person ermouth    schedule 11.06.2015