We’re pleased to announce the GA release of the Couchbase Lite 3.0 and Sync Gateway 3.0 platforms for mobile and edge computing solutions

This major release makes great strides in the area of edge computing by expanding our edge device platform support with the introduction of the C API for Couchbase Lite. The new C API facilitates the use of Couchbase Lite on a broad range of embedded platforms.

In addition, significant architectural enhancements make it simpler to configure and administer the platform. We’ve modularized the Sync Gateway configuration, made it “cluster-aware” and now provide a secure RESTful API endpoint to simplify runtime administration. This in addition to a number of security-related updates. And all that’s just the tip of the iceberg.

This post introduces the significant features of the 3.0 beta release. To learn more about other bug fixes and minor enhancements, check out the Sync Gateway and Couchbase Lite platform-specific release notes.

Dive into the Beta Releases

Here’s how you can start evaluating the new features in Couchbase Lite and Sync Gateway 3.0 beta:

The Couchbase Lite 3.0 Beta Release

C API Support

A few years ago, we released a C API for Couchbase Lite as an engineering labs project. We were overwhelmed by the level of interest and impressed by the range of use cases.

Today we’re happy to announce that we’ll now be officially supporting C API for Couchbase Lite. In the process of productizing the C API, we’ve included support for enterprise-grade features like database encryption, feature parity with other Couchbase Lite platforms, cleaned up the API, optimized the underlying implementation and much more.

Value Proposition

    • C is a lingua franca of programming languages. So it’s easy to build language bindings on top of C API, which means that developers can now build applications on edge devices using a broad range of programming languages such as Python, JavaScript, Rust, Go, etc.
    • The C API is supported on mobile and desktop platforms. Developers can use Foreign Function Interface (FFI) to build bindings for cross-platform languages like Dart. For cross-platform apps with frameworks such as Flutter, developers can build IoT apps in C that run on embedded platforms with a relatively small memory and compute resource footprint compared to a standard desktop or smart mobile device.

Learn more: Documentation.

Client-Side, Field-Level Encryption on Couchbase Lite C Clients

The new C API also supports client-side, field-level encryption, a capability that will be introduced in other Couchbase Lite platforms in future.

Using the new client-side encryption capability, Couchbase Lite C clients can encrypt fields in documents prior to replicating data over the wire to Couchbase Server. Only clients with access to the correct encryption keys can decrypt and read the protected data. The client-side encryption is compatible with the Couchbase Server SDK field-level encryption format.

Value Proposition

    • Enable secure transfer of sensitive data to backend servers, guaranteeing that sensitive data is never leaked to actors that do not have credentials or privileges to access the data.
    • Couchbase Lite applications to encrypt/decrypt sensitive fields in documents using any encryption framework of choice.

Learn more: Documentation.

The SQL++ Query Language for Mobile

In Couchbase Lite 2.0, we introduced the QueryBuilder interface that allowed you to query the Couchbase Lite database using a fluent API with SQL-like semantics. In 3.0, we’re expanding the Query API to support SQL++-formatted query strings (formerly known as N1QL).

SQL++ for Mobile is a Couchbase implementation of an emerging SQL-for-JSON query language. Developers can now submit string-based queries in a familiar SQL-like syntax format. This is in addition to the QueryBuilder API that continues to be supported.

Value Proposition

    • While there are a few differences between Couchbase Lite and Server SQL++ implementations, by and large, app developers can reuse the same queries across Couchbase Server and Couchbase Lite, thereby reducing the effort required to develop, test and optimize their queries.
    • A significant part of the effort in developing bridging plugins for cross-platform or hybrid technologies such as Ionic and React Native is the bridging of the QueryBuilder API. A single string-based API vastly simplifies that effort. Refer to samples below that demonstrate how easy it is to bridge query APIs from JavaScript to Native language.
    • Of course, a string-based API is the only viable option with the C API. With the introduction of C API support, this enhancement was inevitable as we strive to have feature parity across all Couchbase Lite platforms.

Read more: Documentation.

Kotlin Support in Android

We recognize that Kotlin is growing in popularity as the preferred language of choice for developing Android apps.

Prior to the 3.0 beta, Android app developers took advantage of the fact that Kotlin is fully interoperable with Java and could hence use the Android Java SDK for Couchbase Lite within Kotlin apps.

The new release of Couchbase Lite for Android offers a fully-supported, out-of-the-box idiomatic API for Kotlin that enables seamless integration with Android apps developed in Kotlin without the need for custom extensions.

Value Proposition

    • Developers have been asking for it and we listened! Kotlin developers can now adopt common Kotlin patterns within their Android mobile app.

Read more: Documentation.

Auto-Purge Device Data on Channel Access Revocation

Channels are the fundamental mechanism for enforcement of access control using Sync Gateway. They guarantee that only users with access to a specific channel can access documents in that channel.

When a user loses access to a channel and consequently loses access to documents in the channel, Couchbase Lite clients auto purge all local documents on the device that belong to the revoked channel. This is the case as long as the user does not have access to the document via some other channel. This is important for enforcement of data governance and data retention policies.Users can opt out of this feature.

Value Proposition

    • The sync technology enhancements simplify the implementation of complex workflows related to the enforcement of data governance and data retention policies. Here is an example of such a workflow:
      • A sales associate, “Bob”, in charge of “Region_East” is temporarily granted access to a “Region_West” channel. Channels include region specific lead documents.
      • When a new associate is hired for the west region, Bob is revoked access to the “region_west” channel.
      • All previously synced documents must be removed from Bob’s device.

Read more: Documentation.

The Sync Gateway 3.0 Beta Release

Centralized Persistent Modular Configuration

In this release we’re introducing core architectural enhancements that make it simpler for administrators to configure and manage the Sync Gateway.

We’re moving away from the monolithic JSON configuration file to a more modular, “cluster-aware” approach to configuring Sync Gateway nodes in a cluster. Users now only have to specify basic startup configuration that bootstraps a Sync Gateway node and connects it to a Couchbase Server cluster.

Subsequently, users can configure cluster-wide Sync Gateway databases, access control policies, inter-Sync Gateway replications, etc. via the admin REST endpoint. Configuration updates can be made in a modular fashion through the same REST endpoint.

The “cluster-aware” nature of the configuration implies that changes made against one Sync Gateway node are automatically propagated to all or a user-defined subset of Sync Gateway nodes in the cluster. By default, all nodes in a cluster inherit the configuration, but users can scope it to a subset of nodes. Configuration changes made through the REST endpoint are persisted and survive restarts.

Value Proposition

    • Ad hoc database config changes made via the REST API are persisted in corresponding server buckets and are not lost during Sync Gateway restarts – either crashes or deliberate restarts.
    • The ability to centrally update the database config in large clusters simplifies manageability and administration. Database changes made to a node are automatically applied to all nodes in a cluster or can be scoped to a subset of nodes.
    • The ability to securely administer the Sync Gateway cluster using the admin REST endpoint enables programmatic control and simplifies remote administration in cloud deployments without relying on options like SSH-tunneling.
    • Maintaining a monolithic file is difficult especially if the configuration is complex. Multiple Sync Gateway databases may be defined in a single config file. This has potentially undesirable consequences in multi-tenant applications where database changes made for one tenant would require a restart of the node impacting all tenants.

To simplify the migration process, existing JSON configurations will be automatically migrated on upgrade. While users are encouraged to use the new persistent config-based approach, users can continue with the legacy Sync Gateway configuration by setting the disable_persistent_config flag. Then when users are ready, they can migrate to the new approach.

Learn more: Documentation.

Secure Remote Administration

A major enhancement in this release that goes hand-in-hand with the introduction of the centralized persistent config administration is the secure administration of a cluster through the Sync Gateway admin REST API.

New in the 3.0 beta, the admin API enforces authentication and role-based access control by default. The admin API user must be configured on the Couchbase Server as an RBAC user with suitable Sync Gateway roles. Consequently, only authorized users are allowed access to the Sync Gateway admin endpoint.

Value Proposition

    • With authentication support, the admin API can be securely accessed from external clients without the need for network infrastructure-based access control mechanisms (such as SSH tunneling or firewall rules). Remote administration is particularly important in distributed cloud deployments. Backend server applications such as identity servers require programmatic access to the admin REST API for configuring Sync Gateway users.
    • User-level access restrictions offer more flexibility than network-level firewalls.
    • Different applications have different purposes and different users. With this enhancement, only users with a specific Sync Gateway role will be able to administer the Sync Gateway through the admin REST endpoint. Future releases of Couchbase Server will include support for finer-grained Sync Gateway roles that would allow more granular control over the admin functionality. Stay tuned!

Read more: Documentation.

TLS Encryption Enabled by Default

Starting in version 3.0, TLS will be enabled by default on Sync Gateway for Couchbase Server communication ensuring that all server side communication is encrypted by default. This implies that Couchbase Server accesses over using non-TLS schemes such as couchbase:// or http:// will not be permitted by default.

While we strongly recommend always having TLS encryption enabled, we recognize that users may want to disable it for development and testing environments. So users have the option of opting-out of this feature.

Value Proposition

    • With this new default behavior, we’re enforcing and encouraging security best practices.

Read more: Documentation.

User-Defined Extended Attributes (XAttrs) for Access Control Metadata

Prior to version 3.0, Sync Gateway access grant information such as channels and roles had to be embedded within the document body. It is typical to specify the list of channels that a document belongs to as a dedicated property within the document.

With this beta release, users have the option to specify access grants in user-defined Extended Attributes(XATTRs) outside of the document body. The document XAttr is accessible from within the sync function and can be used to make dynamic data routing and access grant decisions as usual.

Value Proposition

    • The separation of access grant metadata from the document body is logical and offers several benefits, including:
      • Embedding access grant metadata within the document body implies that changes to the access grants associated with a document will result in a corresponding update to the document body. The document update in turn triggers a document replication to the clients. Access grant changes are irrelevant to clients resulting in noise. More importantly, if the channel list is large, then the document replications could result in significant bandwidth usage.
      • Embedding channel access grants within the document body makes that information accessible to all users who are syncing that document. This may raise certain privacy concerns. For example, if channel names correspond to user IDs, then a user replicating a document would have knowledge of other users who have access to the document.
      • The data model of existing documents don’t have to be modified in order to retrofit access grant data with a dedicated property. So existing processes and applications don’t have to be modified to use Sync Gateway for data sync.

Of course, we recognize that there are instances where deriving the channel or access grant information based on contents of the document body is the best option. So that option continues to be supported.

Read more: Documentation.

Auto-Purge on Channel Access Revocation in Inter-Sync Gateway Replication

Sync Gateway clusters can replicate data with each other using inter-Sync Gateway replication technology. During replication, if a user loses access to a channel and consequently loses access to documents in the replicating channel, the Sync Gateway on the cluster on which the replication is initiated can be configured to auto-purge the documents in the revoked channel. This is an opt-in feature.

Value Proposition

    • The sync technology enhancements simplify the implementation of complex workflows related to the enforcement of data governance and data retention policies. Here is an example of a workflow:
      • A cruise ship is syncing voyage-specific data from the cloud backend systems. Channels include voyage-specific documents.
      • At the completion of the voyage, the ship is revoked access to the voyage channel.
      • All voyage-related documents on the ship must be purged.

Read more: Documentation.

Conclusion

But that’s not all. There are a number of other enhancements that are discussed in the release notes. Here are direct links to a few helpful resources. You can learn more on our Couchbase Lite and Sync Gateway What’s New pages.

If you have questions or feedback, please leave a comment below or feel free to reach out to me via Twitter or email me.

 

Author

Posted by Madhuram Gupta

All Posts

Leave a reply