NextDB: A Front-End Database Solution

 

I’ve recently been experimenting with a javascript database tool called nextdb.net. NextDB is an open source tool that offers users the ability to build simple databases and store information without ever touching the server. As a small introduction, This is how things have been going so far.

NextDB users begin by making an account. Once logged in, I began by naming and creating a new database and from there I had the option of either building my database from one of three template maps or simply starting from scratch. Since I don’t need much for my testing, I built a table from scratch. The admin interface isn’t much to look at but seems stable enough. Driven by javascript, we can create tables, columns, rows, etc., through a simple GUI. Not many database datatypes are supported (text, date, longinteger, decimal, longbinary), but NextDB is currently an alpha release so we can hope for more to come. As a quick test, I created a “USER” database with three fields; user_id, user_name, and user_pass. Because I am only interested in querying information from the database in this test, I added 5 names to the database again, through the GUI.

Hooking into the newly created database works with stored procedures written in “NextQuery”. The NextQuery scripting language is based off of SQL but I found it annoying at first due to the fact that you have to learn and understand it.

NAME=selectall;
ROW user FROM USER;

This simple stored procedure I’ve named “selectall” and is used to SELECT * FROM USER. You can see the similarity between it and a more common SQL language. The annoyance quickly faded once I got used to the admin query builder. And after combing through the documentation on how to build queries, simple SELECT, UPDATE, INSERT, and DELETE statements became a breeze.

Once I began building my actual website, there were two things necessary to start interacting with NextDB; the NextDBs hosted javascript API (80 KB) and javascript skillz.

var connect = new net.nextdb.Connection("accountname","chat_demo");
var selectAll = new net.nextdb.Query(”selectall”); 

I created a global connection variable (”connect”) that establishes a connection to NextDB and sends over my account name (this was created when I first signed up) along with the database I want to work with, in this case “chat_demo”. The “selectAll” variable creates a new query object and as a parameter, passes over the name of the stored procedure I want to run. The response is my queried data.

connect.executeQuery(selectAll,
function(rows,error) {
if(error) {
net.nextdb.Util.print(error.toString());
} else {
for (var i=0; i < rows[i].length; i++) {
var username = rows[i].user.user_name);
net.nextdb.Util.print(username);
}
}
});

Using my “selectAll” query object, I run a method of my connection object called “executeQuery”. The executeQuery method takes two parameters; the query and a callback function that parses the response of the query.  The callback function will expect a response that will be put into the array “rows” or it will receive an error. As you can see from the statement above, NextDB also offers a class of utilities, one being the Util.print method which creates a nice sort of debugger window for viewing your responses before parsing them.

My simple query is complete and all together, I get this:

var connect = new net.nextdb.Connection("accountname","chat_demo");
var selectAll = new net.nextdb.Query(”selectall”);
connect.executeQuery(selectAll,
function(rows,error) {
if(error) {
net.nextdb.Util.print(error.toString());
} else {
for (var i=0; i < rows.length; i++) {
var username = rows[i].user.user_name;
net.nextdb.Util.print(username);
}
}
});

With my test response, utilizing the print utility, looking like this…

And just like that, I have a working, javascript-driven database. From here, I could remove my print utility and start building off of my rows array.

My overall impression is still a bit phresh and security could pose as a big concern. Because we are constantly making javascript calls to NextDB, sensitive information should be avoided. There is a slight development delay to consider too, due to the fact that a new user needs to learn “NextQuery”.

Other than that, NextDB is winning me over. So far, it’s hella fast and easy to implement. The built in utilities are tight and make testing much easier. According to the docs, you have the ability to relate tables, pass parameters into stored procedures (which may handle some security issues), and all other kinds of fun stuff. I think I’ll continue playing around.

Posted by D. Weatherford

This entry was posted on Wednesday, March 11th, 2009 at 10:41 am and is filed under Technology. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.