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

Question

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

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

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

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

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

Answer 1

Сопровождающий 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 вы должны написать свой собственный.

Answer 2

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

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

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

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

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

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