NanoDB

前两天,我完成了《Node.js高级程序设计》的第一章(吐了一斤狗血似的),澄净让我休息一下来等他。
于是小问就开始动工我在中考之前的一个灵感——前端数据库,在思考进入成熟阶段的时候,我就找到了我的好朋友,著名MongoDB Node.js客户端mongoskin的作者桂林,他在数据库客户端的研究开发方面有着很好的经验,邀请他来合作再适合不过了。

为什么会想到前端数据库?

其实,虽然我专注于Node.js,但并不是一个后端工程师,而是做前端的(就像朴灵)。脑袋里时不时会想出一些产品创意,就会拿起画笔,画一下草稿。
正如桂林和我的另一位好朋友CashLee(李秉俊)所说,在做应用的前端页面时(前后端分离),需要有一个前端数据库作为数据支撑。
然而,NanoDB并不是第一个前端数据库,在此之前有来自W3C的IndexedDB(采用底层接口,有兼容问题,不可移植)和Underscore(不可移植)等。

开发

API

小问是一个忠实的MongoDB粉丝,自然会让NanoDB采用MongoDB风格的API(虽然桂林也曾建议使用Redis风格的API)。
小问觉得MongoDB的原生API是多么有JavaScript原生代码的风格啊(其实MongoDB就大量使用了JavaScript)。 还有API能看出小问是不负责任的。。API由桂林来做。。_(:з」∠)_

存储接口

既然数据库是在前端的,那么就要面临一个问题——存储位置和存储空间。关于这个我们先来说说由桂林建议的存储接口模式(Store Interface)。
http://iwwen.me/NanoDB上,我说明了NanoDB提供一个存储接口的开放API,开发者可以通过选择存储接口来选择存储位置(存储位置决定存储空间),也可以自行开发接口,达到拓展和移植的目的。
NanoDB提供两个接口——memStore和LocalStore。
- memStore即为在内存储数据,也就是说这些数据并不持久化,当程序(当前页面)被卸载时,数据也会被卸载。
- localStore为持久化存储解决方案,也是NanoDB默认的解决方案,数据不随程序卸载而被删除。

桂林给的使用方式也相当有意思:

var myapp = nano.db('myapp', { store: new nano.memStore() });

nano.memStore是一个构造函数,new nano.memStore()创建了一个新的存储对象(有独立存储空间的意味)。

移植

看到这种如此帅的模式,小问不禁想起在当初设想NanoDB的时候,是需要让NanoDB做到可移植的,如十分流行的Adobe AIR、Phonegap、Titanium等等框架,甚至移植到IE6/7。
我去翻了一下Adobe AIR的JavaScript开发者文档,果然就发现一个存储数据的接口,与NanoDB使用的localStorage接口一模一样(也就是为了模仿这个而设计的)。
我把NanoDB核心内部的两个接口修改了一下,就出现了以下代码。

// For Adobe AIR EncryptedLocalStore
function EncryptedLocalStore () {}
EncryptedLocalStore.prototype.get = function (key) {
    return air.EncryptedLocalStore.getItem(key);
};
EncryptedLocalStore.prototype.set = function (key, value) {
    return air.EncryptedLocalStore.setItem(key, value);
};
EncryptedLocalStore.prototype.remove = function (key) {
    return air.EncryptedLocalStore.removeItem(key);
};

var mydb = nano.db('mydb', { store: EncryptedLocalStore() });

那么要如何移植到IE6/7?呵呵,这个可以有,而且已在设计中。(小问没有IE6可以用。。)

后记

感谢老K来帮我写Unit Test。。也感谢因为这半成品而慕名找到我的朋友们。。有大家的支持NanoDB会做的更好!哇咔咔o(*≧▽≦)ツ
今天先到这里,继续写东西去咯~白白,皆さん~