This is more of a feedback then a question.
I’ve been working with your nodeJS SDK for 3 months now and I got to point that it is yet to be reliable for production.
It starts with the fact that your SDK crashes the process, something that should never happen.
Your SDK should capture all errors thrown and pass them as an error to callbacks.
You actually make us wrap async calls with try-catch blocks which is a bad behavior.
Secondly, you break conventions.
Your getMulti, for example, returns a number in the error parameter for callbacks as the amount of documents failed which makes the code loop through the data parameter with if statement to screen the errors from the data.
You should simply return errors in error and data in data. If I wanted an amount I would simply count the keys or the error array’s length.
I have more examples, but I thought to point out that after hearing such good things about couchbase, I am really disappointed to see such unprofessional SDK.
Can you give me an example of a situation where the SDK crashes? This is not something we have really encountered before so I am very curious what situations cause this! Additionally, while you’re right that our async calls sometimes throw exceptions, these are cases where you have passed programatically invalid data (missing a parameter or passing a key which can never be valid) to the method, this should never happen in a production application anyways and is used for debugging.
I am happy to hear you are using Couchbase and am very interested in any other examples you have where the SDK fails to meet your expectations. Please let me know any other pain points you have encountered and I will be happy to incorporate your feedback!
The errors you throw in your SDK have nothing to do with what I pass to the functions I use.
These errors are direct result of faulty logics. I know. I debugged your SDK.
Two examples I remember are:
a JSON.parse on an undefined chuck in your response handler, for which I wrote about in a different topic.
a missing “request_id”, which is an internal mechanism that has nothing to do with the data I pass to a function.
Were either of these the cause of the crashes you’d seen? Any information you can offer would be helpful in helping us identify where you’re running into issues.
Also, I don’t know if you’re running release versions or just what is on github at any given point in time. The great thing about node is that it makes that flexible. We go through a battery of tests before we tag each release. We don’t see any crashes there so maybe there’s an undercovered area. Any pointers on the situation, platform, etc. would be useful so we can try to add test coverage.
The platform is linux.
The version we use is your stable per “npm install couchbase” (currently showing “couchbase”: “~2.1.2” on the package.json).
Yes these were the issues. As I said, I debugged the code to catch where the errors are thrown from.
Here is the log of the request id i mentioned. This crashes the process, causing our forever to restart each time it happens. Obviously, not ideal.
As you can see you are trying to read a property of a null variable, one that the developer has nothing to do with.
It happens sometimes on heavy n1ql queries. That’s all I know.
/home/zeekme/bzeek/node_modules/couchbase/lib/bucket.js:670
err.requestID = jsonError.requestID;
^
TypeError: Cannot read property ‘requestID’ of null
at /home/zeekme/bzeek/node_modules/couchbase/lib/bucket.js:670:32
/home/zeekme/bzeek/node_modules/couchbase/lib/bucket.js:670
err.requestID = jsonError.requestID;
^
TypeError: Cannot read property ‘requestID’ of null
at /home/zeekme/bzeek/node_modules/couchbase/lib/bucket.js:670:32
/home/zeekme/bzeek/node_modules/couchbase/lib/bucket.js:670
err.requestID = jsonError.requestID;
^
TypeError: Cannot read property ‘requestID’ of null
at /home/zeekme/bzeek/node_modules/couchbase/lib/bucket.js:670:32
There have been quite a number of updates to the Node.js SDK since version 2.1.2. Have you tried utilizing one of our new versions and seeing if you can reproduce this?
I’m not going to ask ‘Who wrote this code’ because the real question is, who is the technical manager responsible for releasing code without basic quality procedures. i know the remark sounds blunt , but it seems some criticism could benefit this product development process.