您好,登錄后才能下訂單哦!
本篇內容主要講解“Feed Collection的建模怎么實現”,感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷,實用性強。下面就讓小編來帶大家學習“Feed Collection的建模怎么實現”吧!
MEAN stack 可概括為:
M = MongoDB/Mongoose.js 。流行的數據庫,對 node . js 來說是一個優雅的 ODM 。
E = Express.js :一個輕量級 Web 應用程序框架。
A = Angular.js :一個健壯的框架用于創建 HTML5 和 JavaScript-rich Web 應用程序。
N = Node.js 服務器端 JavaScript interpreter 。
MEAN stack 是 LAMP (Linux、Apache、MySQL,PHP / Python) stack 的一個現代替代者,在九十年代末,LAMP 曾是 Web 應用程序的主流構建方式。
在這個應用程序中并不會使用 Angular.js ,因為這里并不是要構建一個 HTML 用戶界面。相反,這里創建的是一個沒有用戶界面的 REST API,但它卻可以作為任何界面的基礎,如一個網站、一個 Android 應用程序,或者一個 iOS 應用程序。也可以說我們正在 ME(a)N stack 上構建 REST API ,但這不是重點! ##REST API 是什么?
REST 代表 Representational State Transfer,是 SOAP 和 WSDL XML-based API 協議的一個更輕量級替代方案。
REST 使用客戶端-服務器模型,服務器是一個 HTTP 服務器,而客戶端發送 HTTP 行為(GET、POST、PUT、DELETE),以及 URL 編碼的變量參數和一個 URL 。URL 指定了對象的作用范圍,而服務器則會通過結果代碼和有效的 JavaScript Object Notation (JSON) 進行響應。
因為服務器用 JSON 回復,MongoDB 與 JSON 又可以很好地交互,同時所有組件都使用了 JavaScript,因此 MEAN stack 非常適合本用例中的應用程序。在進入開始定義數據模型后,你會看到一些 JSON 的例子。
CRUD 縮略詞常被用來描述數據庫操作。CRUD 代表創建、讀取、更新和刪除。這些數據庫操作能很好地映射到 HTTP 動作:
POST:客戶想要插入或創建一個對象。
GET:客戶端想要讀取一個對象。
PUT:客戶想要更新一個對象。
DELETE:客戶想要刪除一個對象。
在定義 API 后,這些操作將變得更加直觀。REST APIs 中通常會使用的一些常見 HTTP 結果代碼如下:
200 ——“OK”。
201 ——“Created”(和POST一起使用)。
400 ——“Bad Request”(可能丟失所需參數)。
401 ——“Unauthorized”(身份驗證參數丟失)。
403 ——“Forbidden”(已驗證,但是權限不夠)。
404 ——“Not Found”。
RFC 文檔中可以找到一個完整的描述,這個在本博客末尾的參考資料中列出。上面這些結果代碼都會在本應用程序中使用,隨后就會展示一些例子。 為什么從 REST API 開始?
部署一個 REST API 可以為建立任何類型應用程序打下基礎。如前文所述,這些應用程序可能會基于網絡或者專門針對某些平臺設計,比如 Android 或者 iOS 。
時下,已經有許多公司在建立應用程序時不再使用 HTTP 或者 Web 接口,比如 Uber、WhatsApp、Postmates 和 Wash.io 。從一個簡單的應用程序發展成一個強大的平臺,REST API 可以大幅度簡化這個過程中其他接口和應用程序的實現。 ##建立 REST API
這里會建立一個 RSS Aggregator,類似Google Reader,應用程序主要會包含兩個組件:
REST API
Feed Grabber(類似 Google Reader)
本系列博文都將聚焦這個 REST API 的打造,不會去關注 RSS feeds 的復雜性。現在,Feed Grabber 的代碼已經可以在 github repository 中發現,詳情可以見博文列出的資源。下面將介紹打造這個 API 所需的步驟。首先會根據具體需求來定義數據模型:
在用戶賬戶中儲存用戶信息
跟蹤需要被監視的RSS feeds
將feed記錄pull到數據庫
跟蹤用戶feed訂閱
跟蹤用戶會閱讀哪個訂閱的feed
用戶則需要可以完成下列操作:
建立一個賬戶
到feed的訂閱或者退訂
閱讀feed記錄
標記feed/記錄的閱讀狀態(已讀/未讀)
##數據建模
這里不會深入討論 MongoDB 中的數據建模,詳細資料可以在博文后的列舉的資料中發現。本用例需要 4 個 collections 來管理這個信息:
Feed collection
Feed entry collection
User collection
User-feed-entry mapping collection
##Feed Collection
下面一起進入一段代碼,Feed Collection 的建模可以通過下述 JSON 文檔完成:
{ "_id": ObjectId("523b1153a2aa6a3233a913f8"), "requiresAuthentication": false, "modifiedDate": ISODate("2014-08-29T17:40:22Z"), "permanentlyRemoved": false, "feedURL": "http://feeds.feedburner.com/eater/nyc", "title": "Eater NY", "bozoBitSet": false, "enabled": true, "etag": "4bL78iLSZud2iXd/vd10mYC32BE", "link": "http://ny.eater.com/", "permanentRedirectURL": null, "description": "The New York City Restaurant, Bar, and Nightlife Blog” }
如果你精通關系型數據庫技術,那么你將了解數據庫、表格、列和行。在 MongoDB 中,大部分的關系型概念都可以映射。從高等級看,MongoDB 部署支持 1 個或者多個數據庫。1 個數據庫可能包含多個 collection,這個類似于傳統關系型數據庫中的表格。Collection 中會有多個 document,從高等級看,document 相當于關系型數據庫中的行。這里需要注意的是,MongoDB 中的 document 并沒有預設的格式,取而代之,每個 document 中都可以有 1 個或者多個的鍵值對,這里的值可能是簡單的,比如日期,也可以是復雜的,比如 1 個地址對象數組。
上文的 JSON 文檔是一個 Eater Blog 的 RSS feed 示例,它會跟蹤紐約所有餐館信息。因此,這里可能存在許多字段,而用例中主要關注的則是 feed 中的 URL 以及 description 。描述是非常重要的,因此在建立一個移動應用程序時,它會是 feed 一個很好的摘要。
JSON 中的其他字段用于內部使用,其中非常重要的字段是 _id 。在 MongoDB 中,每個 document 都需要擁有一個 _id 字段。如果你建立一個沒有 —— id 的 document,MongoDB 將為你自動添加。在 MongoDB 中,這個字段就是主鍵的存在,因此 MongoDB 會保證這個字段值在 collection 范圍唯一。 ##Feed Entry Collection
在 feed 之后,用例中還期望追蹤 feed 記錄。下面是一個 Feed Entry Collection 文檔示例:
{ "_id": ObjectId("523b1153a2aa6a3233a91412"), "description": "Buzzfeed asked a bunch of people...”, "title": "Cronut Mania: Buzzfeed asked a bunch of people...", "summary": "Buzzfeed asked a bunch of people that were...”, "content": [{ "base": "http://ny.eater.com/", "type": "text/html", "value": ”LOTS OF HTML HERE ", "language": "en" }], "entryID": "tag:ny.eater.com,2013://4.560508", "publishedDate": ISODate("2013-09-17T20:45:20Z"), "link": "http://ny.eater.com/archives/2013/09/cronut_mania_41 .php", "feedID": ObjectId("523b1153a2aa6a3233a913f8") }
再次提醒,這里同樣必須擁有一個 _id 字段,同時也可以看到 description、title 和 summary 字段。對于 content 字段,這里使用的是數組,數據中同樣儲存了一個 document。MongoDB 允許通過這種方式嵌套使用 document,同時這個用法在許多場景中也是非常必要的,因為用例往往需求將信息集中存儲。
entryID 字段使用了 tag 格式來避免復制 feed 記錄。這里需要注意的是 feedID 和 ObjectId 的用法——值則是 Eater Blog document 的 _id 。這提供了一個參考模型,類似關系型數據庫中的外鍵。因此,如果期望查看這個 ObjectId 關聯的 feed document,可以取值 523b1153a2aa6a3233a913f8,并在 _id 上查詢 feed collection,從而就會返回 Eater Blog document。 ##User Collection
這里有一個用戶需要使用的 document :
{ "_id" : ObjectId("54ad6c3ae764de42070b27b1"), "active" : true, "email" : "testuser1@example.com", "firstName" : "Test", "lastName" : "User1", "sp_api_key_id" : "6YQB0A8VXM0X8RVDPPLRHBI7J", "sp_api_key_secret" : "veBw/YFx56Dl0bbiVEpvbjF”, "lastLogin" : ISODate("2015-01-07T17:26:18.996Z"), "created" : ISODate("2015-01-07T17:26:18.995Z"), "subs" : [ ObjectId("523b1153a2aa6a3233a913f8"), ObjectId("54b563c3a50a190b50f4d63b") ], }
用戶應該有 email 地址、first name 和 last name。同樣,這里還存在 sp_api_key_id 和 sp_api_key_secret —— 在后續部分會結合 Stormpath(一個用戶管理 API )使用這兩個字段。最后一個字段 subs,是 1 個訂閱數組。subs 字段會標明這個用戶訂閱了哪些 feeds。 ##User-Feed-Entry Mapping Collection
{ "_id" : ObjectId("523b2fcc054b1b8c579bdb82"), "read" : true, "user_id" : ObjectId("54ad6c3ae764de42070b27b1"), "feed_entry_id" : ObjectId("523b1153a2aa6a3233a91412"), "feed_id" : ObjectId("523b1153a2aa6a3233a913f8") }
最后一個 collection 允許映射用戶到 feeds,并跟蹤哪些 feeds 已經讀取。在這里,使用一個布爾類型(true/false)來標記已讀和未讀。 ##REST API 的一些功能需求
如上文所述,用戶需要可以完成以下操作:
建立一個賬戶
到 feed 的訂閱或者退訂
閱讀 feed 記錄
標記 feed / 記錄的閱讀狀態(已讀 / 未讀)
此外,用戶還需求可以重置密碼。下表表示了這些操作是如何映射到 HTTP 路由和動作。
在生產環境中,HTTP(HTTPS)安全需求使用一個標準的途徑來發送敏感信息,比如密碼。 ##通過 Stormpath 實現現實世界中的身份驗證
在一個魯棒的現實世界應用程序中,提供用戶身份驗證不可避免。因此,這里需要一個安全的途徑來管理用戶、密碼和密碼重置。
在本用例中,可以使用多種方式進行身份驗證。其中一個就是使用 Node.js 搭配 Passport Plugin ,這個方式通常被用于社交媒體賬戶驗證中,比如 Facebook 或者 Twitter 。然而,Stormpath 同樣是一個非常不錯的途徑。Stormpath 是一個用戶管理即服務,支持身份驗證和通過 API keys 授權。根本上,Stormpath 維護了一個用戶詳情和密碼數據庫,從而客戶端應用程序 API 可以調用 Stormpath REST API 來進行用戶身份驗證。
下圖顯示了使用 Stormpath 后的請求和響應流。
詳細來說,Stormpath 會為每個應用程序提供一個安全秘鑰,通過它們的服務來定義。舉個例子,這里可以定義一個應用程序作為「Reader Production」或者「Reader Test」。如果一直對應用程序進行開發和測試,定義這兩個應用程序非常實用,因為增加和刪除測試用戶會非常頻繁。在這里,Stormpath 同樣會提供一個 API Key Properties 文件。Stormpath 同樣允許基于應用程序的需求來定義密碼屬性,比如:
不低于 8 個字符
必須包含大小寫
必須包含數字
必須包含 1 個非字母字符
Stormpath 會跟蹤所有用戶,并分配他們的 API keys(用于 REST API 身份驗證),這將大幅度簡化應用程序建立過程,因為這里不再需要為驗證用戶編寫代碼。 ##Node.js
Node.js 是服務器端和網絡應用程序的運行時環境。Node.js 使用 JavaScript 并適合多種不同的平臺,比如 Linux、Microsoft Windows 和 Apple OS X。
Node.js 應用程序需要通過多個庫模塊建立,當下社區中已經有了非常多的資源,后續應用程序建立中也會使用到。
為了使用 Node.js,開發者需要定義 package.json 文件來描述應用程序以及所有庫的依賴性。
Node.js Package Manager 會安裝所有庫的副本到應用程序目錄的一個子目錄,也就是 node_modules/ 。這么做有一定的好處,因為這樣做可以隔離不同應用程序的庫版本,同時也避免了所有庫都被統一安裝到標準目錄下造成的代碼復雜性,比如 /usr/lib。
命令 npm 會建立 node_modules/ 目錄,以及所有需要的庫。
下面是 package.json 文件下的 JavaScript:
{ "name": "reader-api", "main": "server.js", "dependencies": { "express" : "~4.10.0", "stormpath" : "~0.7.5", "express-stormpath" : "~0.5.9", "mongodb" : "~1.4.26”, "mongoose" : "~3.8.0", "body-parser" : "~1.10.0”, "method-override" : "~2.3.0", "morgan" : "~1.5.0”, "winston" : "~0.8.3”, "express-winston" : "~0.2.9", "validator" : "~3.27.0", "path" : "~0.4.9", "errorhandler" : "~1.3.0", "frisby" : "~0.8.3", "jasmine-node" : "~1.14.5", "async" : "~0.9.0" } }
應用程序被命名為 reader-api,主文件被命名為 server.js,隨后會是一系列的依賴庫和它們的版本。這些庫其中的一些被設計用來解析 HTTP 查詢。在這里,我們會使用 frisby 作為測試工具,而 jasmine-node 則被用來運行 frisby 腳本。
在這些庫中,async 尤為重要。如果你從未使用過 node.js,那么請注意 node.js 使用的是異步機制。因此,任何阻塞 input/output (I/O) 的操作(比如從 socket 中讀取或者 1 個數據庫查詢)都會采用一個回調函數作為最后的參數,然后繼續控制流,只有在阻塞操作結束后才會繼續這個回調函數。下面看一個簡單的例子來理解這一點。
function foo() { someAsyncFunction(params, function(err, results) { console.log(“one”); }); console.log(“two”); }
在上面這個例子中,你想象中的輸出可能是:
one two
但實際情況的輸出是:
two one
造成這個結果的原因就是 Node.js 使用的異步機制,打印 「one」 的代碼可能會在后續的回調函數中執行。之所以說可能,是因為這只在一定的情景下發生。這種異步編程帶來的不確定性被稱之為 non-deterministic execution 。對于許多編程任務來說,這么做可以獲得很高的性能,但是在順序性要求的場景則非常麻煩。而通過下面的用法則可以獲得一個理想中的順序:
actionArray = [ function one(cb) { someAsyncFunction(params, function(err, results) { if (err) { cb(new Error(“There was an error”)); } console.log(“one”); cb(null); }); }, function two(cb) { console.log(“two”); cb(null); } ] async.series(actionArray);
到此,相信大家對“Feed Collection的建模怎么實現”有了更深的了解,不妨來實際操作一番吧!這里是億速云網站,更多相關內容可以進入相關頻道進行查詢,關注我們,繼續學習!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。