Web applications have been evolving on a daily basis, mainly because web is something so visible that will be shamed if your website is not at the same level of your competitors.
For years the languages and frameworks to build websites changed to fill the demand of new agile development methodologies, servers like nodejs appeared to deal with changes, jquery appeared to allow the creation of richer content, etc. you'll notice the evolution started from front-end technologies and it's moving towards the backend, now it's the time for the ultimate frontier to adjust to this change.
Evolution of the database model
One of the things that remains constant over the years is the need to map your information to storage applications like MySQL, Oracle database, Postgres or SQL server. One thing they have in common it's all of them are based on a rigid model, the model of tables, rows and columns, and these lead to several problems, these problems you need to address during this always changing web environment.
- Managing the instructions at code level to work with a new set of data or new columns at the database level.
- Addressing deployment problems, if you create a new field in a table you'll need to take down your server and do a painful process of upgrading, (run scripts to change your tables, execute an script to migrate, or at least update, your new model, and finally updating the code that changed)
What if these changes means that your model changed in a more radical way? What if you created a new type of product that requires a full new model? That's something to thing about.
This kind of problems have been a constant over the years until now, some software developers, as myself, started to wonder if there will be a better way to store the information that is more aligned with the current challenges, that's how the NoSql movement started, as a way to solve this new data model paradigm.
The new data model
To give a better explanation about how NoSQL address the problem of these always changing data models, let's work using an example as a basis. Lets assume we're going to store customers from our newly created website, to do this job we decided to create a table in an RDBMS, and we included columns like name, last name and genre. After some days we put together an application and finally it's running on web, then tweet about giving some benefits to the people that register during the weekend, after a good weekend you end up with 3M records, you're surprised because you didn't expected that kind of traffic, then you check the db and realized that you didn't provide enough space for some long last names and some of them are truncated, darn you'll need to expand the column.... But, you can not change the size of a column in SQL server, you need to create a new table, move the records and that will mean your server will be out for 1 hour. Does this sound familiar? Even worst, you need to include some new fields in the process, meaning changing the HTML, your server side, doing some migration, etc.
Although JSON does not solve all the problems that come with these kind of changes it's really easy to update the underlining model just modifying a JSON structure than changing the tables, columns, rows and SQL statements, and that's how NoSQL helps in the development of web application, allowing to make this kind of changes easily, storing JSON instead of traditional data model.
A Customer could be model in a JSON like this:
{
name: "John",
lastName: "Smith",
genre: "Male"
}
Same problem stated before, what if you need to store a longer last name? Because the model is not rigid, your users will never had the problem in the first place, and their last names were not truncated. What if you need to store new information?
{
name: "John",
lastName: "Smith",
genre: "Male"
}
{
name: "Peter",
lastName: "Korn",
genre: "Male",
email: "test@mycompany.com"
}
Done!, you don't need to change anything at the database level. If your REST services are treated as general REST services that get JSON and post them to the DB, you will not need to change your backend either, and the only change you will need is at the HTML and javascript level, which will allow you to do a cleaner deployment of the new version, just post the new HTML and javascripts at the web sever folder and that's it, you are ready to go.
Conclusions
Although a good requirements/design/test will always be better than having to get into a production environment to realize that you forgot a piece of data that is really important to your business, the NoSQL databases allows you to upgrade your applications easier, and relieves the pain of creating an application from ground up, it really empowers the developer to explore the data structure while he is creating his master piece.
Later I will keep exploring samples on how to use NoSQL to create applications in a faster/easier way, in the mean time please go to here: http://djondb.com/blog and check out some of the full examples that you will find in there.