Why shouldn't the REST API be used CRUD operations?

Other topics on this subject are 2 or 3 years old. But, the 3.0 documentation still has a tip about using an SDK rather than REST.

Is this till current advice? If so, why?

I’d like to use REST rather than the node.js SDK to avoid use of the native code libcouchbase which introduces several problems for me with mockery and the Serverless framework.

Apologies for the delayed response.
The main issue here is performance and test completeness. We have not tested and optimized the REST API for latency and throughput. Do you have the specifics on the issues you are seeing with libcouchbase in node.js? It will help us lobby.

Thank you for the reply.

The problem with libcouchbase was its use of native code; this made deployment to AWS Lambda much more complicated because the lib has to be built on a compatible linux box rather than my mac development system.

I “solved” the problem by switching from couchbase to AWS Dynamo.

Sorry to hear that @chuck but thanks for telling us about the problem.
One option I should also mention is N1QL - N1QL does REST and have full INSERT/UPDATE/DELETE capabilities.

Find details here on how to program in REST here:

I cannot comment on Node.js, but in Elixir, NIFs that use libcouchbase have absolutely no protection against segfaults. Normally, in Elixir, you can protect against crashes by using supervised processes, but when a NIF crashes, I believe it takes down the entire VM. I love Couchbase, but without a REST API to do CRUD operations, it just isn’t feasible for me to use, due to the risks libcouchbase presents to my project.

I’m not sure the complexity of integration, but there are some other pure erlang clients. Also, I think the NIF taking down the entire process is more of an implementation issue than a design, constraint, right?

No. It is just an issue with the way Erlang interacts with NIFs. You also cannot effectively put NIFs into processes, so it is recommended that any NIF calls take less than a millisecond.