Continuing from the Sync Gateway technical series, we will look specifically at how to configure the Sync Function through the use of Channels to execute data orchestration. In the video below, we are joined by Chris Anderson who will go over an example on how to do data routing. We talked about access controls previously and Channels provide READ access to users between the mobile client and the remote database. The example is taking questions from Stackoverflow and loading them into Sync Gateway where only specific questions and therefore specific tags of topics that the user is interested will be synced. From the tags, the Channel names may be generated. This is how subsets of data are synced down to mobile accordingly to user’s interest.
Channels
The tags are used as the Document Type key and is a way for accessibility control on specific documents in the database. How this is done is using a JavaScript function that is built inside Sync Gateway where we are able to have each document come through and route the document to the particular channel they belong to. We are able to pass the array of tags to the channel function to create the channel names dynamically.
|
1 2 3 4 5 6 7 8 9 10 |
{ ... “tags” : [ “android”, “java”, “nosql”, “couchbase" ], ... } |
The Sync Gateway JSON configuration file will include the sync function where the array of tags are passed into the channel function.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
{ "log" : ["REST"], "databases" : { "db": { "server" : "walrus:." "users": {"GUEST" : {"disabled" : false, "admin_channels": ["*"] }}, "sync" : function(doc) { channel(doc.tags); } } } } |
In the Couchbase administration console, the channel of different tags are displayed with respective content that is captured. This console helps with developing your Sync Function logic and gather the relevant information you are trying to define.
Replication
A mobile client is then able to synchronize the relevant user content by using the Couchbase Lite built in replication API. Below is an example of Objective-C code that deals with setting up the user’s topic interest on the client side to pull relevant data. The replicator will then know how to interact with the data from within the channels. We first create a Pull replication
|
1 2 3 4 |
CBLReplication *pull = [database createPullReplication: url]; pull.channels = @[@“android”, @“java”, @“nosql”]; [pull start]; |
The replicator will interact with the specific channel names to bring the data down to the mobile devices. If the specific channels are not set then all the data that exists will be pull down from Sync Gateway. This is also where we are able to have an asynchronous experience for users being offline. When the connection is available, the syncing of new data from those channel tags will resume.
How that is done is through the changes feed API, db/_changes from Sync Gateway where the feed is made up meta data of these documents. The revision identifier _rev is used by the client to skip pulling down documents of particular versions that they already have so that it allows for efficient reconnection. What powers the synchronization is the sequence number where it is used by the client to tell Sync Gateway at which particular sequence to resume for new content. The “last_seq” key is an integer that represents the last change that the client has synced down.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
{ ... - { seq: 116, id:"123123kj12h310193", - changes: [ - { rev: "1-12313124324" } ] }, - { seq: 117, id:"191123kj12h310193", - changes: [ - { rev: "1-12398124378" } ] } ], last_seq: "117" } |
From the Sync Gateway blog series, we are able to validate document types further as well as provide security through authorizing users in sync gateway. To learn more about how to develop and troubleshoot channels in Sync Gateway, be sure to read the training guides for more insights.
