Best Practices

      +
      Speed up your application development, with some best practices for using Couchbase SDKs.

      From batching and reactive APIs, to unit tests and handling errors. There’s plenty that can be done to remove bottlenecks in development and in performance, and this page can be your checklist of areas not to neglect as you develop your app.

      Security

      But before worrying about bottlenecks, let’s put security concerns first.

      Security is a process, and not just a set of checkboxes — but

      Roles and RBAC

      Self-managed Couchbase Server uses Role-Based Access Control (RBAC), which is reflected in our managed service as a nuanced set of Roles. Data security depends in part on only giving access to

      RBAC restrict resources on a Couchbase cluster to an identified user, allocated by role.

      Users, Resources, Roles, and Privileges

      Couchbase Server Enterprise Edition uses Role-Based Access Control for applications to restrict resources on a Couchbase cluster to an identified user.

      Each user who attempts resource-access is identified by means of the credentials they pass to Couchbase Server, for purposes of authentication: these consist of a username and (typically) a password. Once the user is authenticated, an authorization process checks the roles with which the user is associated. If one or more of these roles correspond to privileges that permit the user-requested level of resource-access, access is duly granted; otherwise, it is denied.

      Users who have been assigned the Admin role for the cluster are able to create, edit, and remove users. The SDK provides APIs to support these activities.

      Introductory examples in the SDK documentation use the Administrator user to ensure that developers can quickly get up and running; this should not be used in production. Elsewhere we use a general "user" which represents whichever permission levels are appropriate to your application.

      Performance

      Couchbase’s Data Service uses a fast binary protocol, which will always outperform JSON streamed over HTTP from SQL++ queries. If you know the key (ID) of a document, then use the Data Service.

      If you need pessimistic logging, in particular if you need to lock documents for multi-document ACID transactions, then anything you can do at the schema level to reduce the number of documents locked simultaneously wil remvoe a bottleneck to updating the affected documents.

      Dealing with Timeout Errors

      Concurrency and Async APIs

      See the Async & Reactive APIs page for practical examples.

      Error Handling

      Best practices for error handling in C++ depend somewhat upon your choice of API: future, or callback based, as covered in the async and reactive API guide. That guide also covers how errors are actually returned and handled. Your application should always check if an operation returned an error, and potentially handle any specific error codes that may have returned. See also the error handling guide, which covers specific errors, along with a broader look at error handling strategies.

      Threshold & Orphan Logging

      Observability is provided by the SDK in the following ways:

      Threshold Logging

      Threshold logging is the recording of slow operations — useful for diagnosing when and where problems occur in a distributed environment. It is enabled by default.

      You will see this information turning up in the logs something like this:

      Threshold Log: {"service":"kv","count":2,"top":[{"operation_name":"Insert","total_us":161679},{"operation_name":"Upsert","total_us":161451}]}

      And as tracing values such as total_us, the duration of the total time taken for the operation, expressed as microseconds.

      Orphaned Response Reporting

      Special reporting capabilities which explicitly collect information about responses which have been abandoned (i.e. timed out) at the time when the SDK tries to complete them. This is also enabled by default.

      Additional Information

      SDKs are client to Couchbase Server — whether Capella Database-As-A-Service, or self-managed — and in some areas it would be wise to take a fully rounded approach. Read up on security and performance considerations relevant to your use case.

      Role-Based Access Control

      All aspects of the Couchbase RBAC system are covered in the section Authorization. Specifically, for information on: