NodeJs and Apache Cassandra

The next topic for my project was learning about alternative ways for interaction between NodeJs and the Apache Cassandra database.

As a background I am new to the Apache Cassandra environment. In fact, my recent background is in MEAN (MongoDB, ExpressJs, AngularJs, NodeJs). In that world the mapping between MongoDB documents and NodeJs artifacts is well understood and frankly it is one of simplest and most natural Object-Database Mapping (ODM) that I have seen. I am a fan of that approach.

It is not perfect and there is always a tradeoff of productivity vs. efficiency. In previous projects we have found a middle ground where most of the work was done with Mongoose letting the package do its magic and letting us focus more on our application, and only if and when needed, overwriting these commands, getting into the dirty details and implementing optimizations to the needed degree. As the saying goes “keep simple things simple and make complex things possible”.

With that in mind let’s look at the top packages I am using for my NodeJs-Cassandra project:

The first excellent package to consider is DataStax Node.js Driver for Apache Cassandra. Everyone simply call this the cassandra-driver and you can find it here. I found the package to be stable, complete and regularly updated. It provides a direct access to the Cassandra Query Language also known as CQL.

As a very simple example, here is a call to fetch all employees in a department:

findeployeesindepartment

The two aspects to highlight is the connection to the database:

var db = new cassandra.Client(
{ contactPoints: ['127.0.0.1'],
protocolOptions: {port: 9042},
keyspace: 'myDB'});

And the call to execute a command (in this case “SELECT” command):

var query = 'SELECT * FROM employees WHERE department = ?';
db.execute(query, [department], function(err, result)...

Note that when executing a command there is a method here to pass parameters to the command. The parameters use are marked with question-mark character inside the CQL command. The values are passed to the execute command as an array of ordered values (i.e. the order in which the the question-marks appear in the command).

All of this is simple enough and useful but it requires me to get into the CQL level and implement manually a set of classes to map database entities to NodJs artifacts. I intend to use this package directly every time there is a need to get to the deeper command level optimization. This is for the complex cases.

Back to the MEAN background, what about the simple cases? Is there a way to have a basic object mapping done transparently, something similar to Mongoose for MongoDB in the MEAN world?

Not to worry. Someone already built a package for that. It is called Cassie-ODM or simply Cassie and it currently in Beta. I gave it a run and liked it a lot. More on that next time.

Advertisements

Angular 2 data-binding

The next topic I was struggling with is the nuances of the way data-binding is done in Angular-2 and how it is mapped to what I know from AngularJs (Aka Angular-1).

There is a tone of content about it. But at least to me it was a bit messy. There is also a huge amount of Q&A in stackoverflow with reports that data-binding do not work for different users (see this and this and this as examples). I guess I am not alone…

Here is the good news. I found the following blog as the cleanest overview of the Angular-2 data-binging and how it is mapped to the familiar Angular-1 directives.

Introduction to data binding in Angular 2 versus Angular 1

Thank you Siebe Hiemstra. This one helped me!

Angular2 OrderBy and Filter Pipes

Angular2 seems to include a lot of the real life lessons learned from AngularJs (aka Angular1). That is great. However, it feels to me that sometimes the Angular team, with the best intentions, took a purist view. They have the right reasoning, they want to protect us (the developers) from ourselves, but the outcome is that simple things are no longer simple.

Here is a specific example for that:

The ability to filter and sort array of elements in the Angular view code without too many lines of codes.

In Angular1 we could have done the following:

<li ng-repeat=”emp in employees | orderBy : ‘office-number’”>{{emp.full_name}}</li>

(See more complex snippet here).

That option of doing an oderBy on the fly in the view was wonderful. It did come in a price as the Angular engine made the determination of when to run the orderBy, there were many cases that this expensive sort operation was executed an insane amount of times slowing down the entire page. So i really do get what the Angular team was trying to do. But still…it is annoying that this can’t be done this way anymore. I now have to write code somewhere else to implement what should have been part of the platform.

See more of the details about Pipes in Angular2:

https://angular.io/docs/ts/latest/guide/pipes.html

Also see more about the explicit decision not to include these functions:

https://angular.io/docs/ts/latest/guide/pipes.html#!#no-filter-pipe

More Angular 2 Baby Steps

For the past couple of weeks I’ve been drowning in huge amount of new information, trying to self-learn with the help of my fellow developers what is Angular2 and how to build modern NodeJS+Angular2 projects.

Well the process is not easy. There are tones of write-ups and tones of opinions. New insights become obsolete in very short time and one can never be sure if what is written is even still applicable and if it is in any way best-practice.

I found myself a bit overwhelmed. I was not sure where/how to start this exciting journey.

Here are few things and data sources I’ve used so far:

Perhaps the first iteration that I had was with the Tour Of Heroes tutorial. While there are several things I would probably do differently now, IMHO this is still the best way to start.

The second thing that I was searching for is how to structure a project if you have backend APIs using Express and client side using Angular2. To tell you the truth that was not easy for me and what helped me was the MEAN App with Angular 2 tutorial. It is not perfect for what I need but it sure gave me an insight into some of the consideration on how to organize my project.

The next obstacle for me was the integration with Bootstrap.  In AngularJS (or Angular 1) I used the Angular-UI package. The same team also delivers now Angular 2 support. However, I gave the ng2-bootstrap package a try and at least for me it did the work well and seems to be a bit more native to angular 2.

With these initial set of packages and tutorials I felt good enough to start to experiment with this brand new world of Angular 2. This is just the beginning. Stay tuned…

 

Baby steps in Angular2

My last couple of projects were developed in MEAN (just in case it means MongoDB, Express, AngularJS and NodeJS). Specifically on AngularJS (I guess now it is called Angular1), we achieved some great results in building a web site that is responsive and modern for both desktops and mobile. It was also great to have JavaScript used both in the backend and front end.

And here comes Angular2…

I’m now about to start a new project, all from scratch, and this project has both new constrains as well as new opportunities to continue to evolve the software stack.

On the database side there is a constraint to use Cassandra and that is probably a topic for a different writeup. On the client side, the team also wanted to naturally see what all the noise about Angular2 means (Angular2 arrives-Sep 2016).

We are just starting so this is all new to me and reflective the initial study and running tutorials only (Quick Start and Tour Of Heroes).

My first reaction is that Angular2 is simply a new animal. The known concepts from AngularJs did not smoothly move to the new framework. Also, the transition to Angular2 also requires (or at least recommend) to transition the development language to Typescript, that I do not know. Hence the removal of the Js from the name.

For me that means an unexpected disruption in my personal growth. Restarting the client side technology learning almost from the beginning. I suspect that this is true for many developers.

From a longer term perspective this is probably something good, the platform seems to have tons of promises for faster to load applications and better balance between server side and client side processing. I can imagine that in couple of years and additional releases, the platform will become a major platform. Mastering it early is probably something positive.

But on the immediate timeframe that is a real setback…