The Quality of node.js SDK for Azure
I do not know the exact reasons of this but node.js SDK for Azure is not in the state I wanted it to be. On the surface everything looks right. The project is actively developed and is available for over two years now, so you expect it rock solid. The problem is the more you use it, the more you see it is not.
In my current work I mostly use from the node.js SDK everything related to the Azure Table Storage. I expect that Azure Storage in general and Azure Service Bus are two elements that you likely will use most often in node.js projects even outside of Azure Cloud. Service Bus is now less dependant on SDK with introduction of AMQP protocol, as you can now use any of the AMQP clients available for node.js.
What worries me is that I’ve found in a two years project (Azure Table Storage is available from beginning) 3 issues from which two are really important ones (optimistic concurrency etag guarding was not working or utf-8 was not working in batch commits. Those issues are really important and at least one of them was first issues over a year ago! This makes me think about two possibilities:
- almost nobody is using node.js SDK for Azure so important issues are not found and fixed,
- this SDK is not taken seriously and not have enough attention.
The issues were serious enough and there are even more peculiarities related to usage of batch commits that I even started tow think about creating a separate SDK related only to Azure Storage (especially that JSON support to Table Storage is coming soon). I also start to think that current SDK is maybe to big (I use maybe 15% of it) and separation to several elements updated independently would be a better approach. Currently I have not enough time to start own node.js SDK limited only to Azure Storage but when JSON support will be ready I’ll reconsider it starting with Table Storage. I should be much easier with JSON available…