Html5本地數據存儲和跨設備同步

Question

我正在構建一個全功能的Web應用程序。當然，您可以在「離線」模式下保存到本地數據存儲。我希望能夠跨設備進行同步，以便人們可以在一臺機器上工作，保存，然後在另一臺機器上加載並加載它們的內容。

的問題是：

1）它是一個壞主意，在服務器上存儲JSON？爲什麼在將服務器上的json解析爲模型對象時，只要將它作爲json傳遞迴（其他）客戶端？

2）我不知道我是否想爲此嘗試NoSql技術。我不打破JSON，現在數據庫中唯一的關係是從用戶帳戶到他們的條目。除了用戶數據之外，域模型將是一個String，它是json。忠告歡迎。

理論上，將來我可能想在服務器上做一些處理或者建立更復雜的關係。換句話說，現在我只想保存JSON，但是在將來我可能需要一個更傳統的關係系統。 NoSQL的方法會妨礙這個嗎？

3）有沒有這方面的安全問題？ JS注射例如？理論上，對於這個用例，用戶至少現在不會輸入任何內容。

預先感謝您。

編輯 - 感謝答案。我選擇了我做的答案，因爲它詳細介紹了NoSql的優缺點。

Answer 1

JSON在服務器

這不是一個壞主意來存儲JSON在服務器上，特別是如果你去一個NoSQL的解決方案類似的MongoDB或CouchDB的。兩者都使用JSON作爲它們的本地格式（MongoDB實際使用BSON，但它非常相似）。

NOSQL方法：假設的CouchDB如複製和併發處理存儲引擎

• 烤
• 很簡單REST API，跟與HTTP的數據的基礎上。
• 數據存儲爲原生JSON而不是斑點或文本字段
• 強大的搜索/查詢引擎，讓你不斷成長的文檔
• 離線模式的複雜性。您可以使用javascript直接與CouchDb交談，並且如果互聯網不可用，則整個應用程序將繼續在客戶端上運行。

安全

確保您解析用的browers JSON.parse或JavaScript庫是安全的（json2.js）的JSON文件。

結論

我覺得跟NOSQL我建議的理由去這裏，CouchDB的特別，就是它要處理所有的堅硬的東西給你。複製將很快成爲安裝。你不必擔心併發性等。

這就是說，我不知道你在建什麼樣的App。我不知道你和客戶的關係是什麼，讓他們把CouchDB放到他們的機器上會是多麼容易。

鏈接

1. CouchDB @ Apache
2. CouchOne
3. CouchDB the definitive guide
4. MongoDB

更新：

看完應用後，我不認爲CouchDB將會是一個很好的客戶端選項，因爲您不需要人們安裝數據庫引擎來播放soduku。這就是說，我仍然認爲這將是一個很好的服務器端選項。如果您想將服務器CouchDb實例與客戶端同步，您可以使用類似BrowserCouch這是CouchDB的本地存儲的JavaScript實現。

Answer 2

1. 如果大多數處理將在客戶端使用JavaScript完成，但在將JSON直接存儲在服務器上時看不到任何問題。

2. 如果你只是想利用新技術，你很樂意嘗試一些不同的東西，但是對於大多數應用程序來說，離開傳統數據庫並沒有真正的理由，而SQL使生活變得簡單。某些瀏覽器（Firefox 3.5以上版本，例如）已經有一個原生版本，而Crockford的json2.js可以複製別人這個功能 -

3. ，所使用的標準JSON.parse函數來解析JSON字符串你是安全的，因爲長。

Answer 3

剛剛看了你的帖子，我不得不說，我很喜歡你的方法，它預示着這樣許多Web應用程序可能會在今後的工作中，既有本地存儲的元素（斷開狀態）和在線存儲（主數據庫 - 將所有客戶記錄保存在一個地方並與其他客戶端設備同步）。

這裏是我的答案：

1）中存儲JSON在服務器：我不知道我將存儲的對象爲JSON，它可以這樣做，如果你的應用程序是非常簡單的，然而，這將妨礙使用這些數據的努力（例如運行報告並通過電子郵件發送給批處理作業）。我寧願使用JSON來傳輸我自己的信息以及用於存儲它的SQL數據庫。

2）NoSQL方法：我想你已經在那裏回答了你自己的問題。我的首選方法是現在設置一個SQL數據庫（如果所需的額外資源不是問題），那麼您可以爲自己設置NoSQL的數據訪問層節省一些工作，因爲您可能必須將其刪除在將來。如果你不想要一個全功能的RDBMS，SQLite是一個不錯的選擇。

如果編寫一個模式太麻煩了，而您仍然希望將JSON保存在服務器上，那麼您可以使用單個表格散列JSON對象管理系統，並在服務器端解析某個JSON對象以返回相關記錄。這樣做會比保存/刪除文件更容易，所需的權限也更小。

3）安全性：你提到有目前沒有用戶輸入：

「用於該用途的情況下，用戶並不 獲得進入任何事情」

但在問題剛開始的時候你也提到用戶可以在一臺機器上工作，保存，然後得到

另一臺機器上，如果是這樣的話，那麼你的申請將被存儲用戶數據加載其 東西」

，沒關係，你還沒有提供一個很好的圖形界面爲他們這樣做，你會不得不擔心多個角度的安全問題，而且類似的工具只能解決一半的問題（客戶端）。

基本上，您還必須檢查服務器上的POST請求的內容，以確定要發送的數據是否有效且真實。在保存到數據存儲之前，需要在服務器上（使用php或其他類似語言）驗證JSON對象的完整性（或者您要綁定的任何數據），這是因爲有人可以輕鬆繞過您的javascript層「安全性」並篡改POST請求，即使您不打算這樣做，然後您的應用程序將無論如何將惡意輸入發送出客戶端。

如果你已經整理了服務器端的東西，那麼JSON.parse在防止JS注入方面會變得有點過時。如果您依賴遠程網站API來獲取一些數據，那麼還有額外的一層也不錯。

希望這對你有用。