Architectural information for a Server/Mobile app

Mobile
1

Hello,
I’m fairly new to the couchbase world, so excuse me if I say stupid things.
The last week, I have read documentation, and made a few test on couchbase. Here i would like to ask some basic questions:
I have to implement a solution with multiple client (100 or so).
Clients are Windows 8.1 (no RT) tablet, or Windows 7 pc.
They do not always has connection.
Clients has some information to be synched with a database on Server side. And some other that just have to be logged to the server, like: save the document to the server bucket and then delete from the client.
Synched documents are in the order of 1000 per clients. Logged documents are more, let’s say 5000 documents per client every day.
Synched document are generated Server side (by an administration application that connects to the server bucket).
Logging documents are generated Client side.
At present I’ using this components:
– Server:

  • couchbase server 3.0.1: two buckets (one for the main data, the other used by the sync gateway for shadowing)
  • sync gateway 1.0.3: implements a sync function that sends documents to the specific channel (i.e. to a client application)
    – Client application:
  • .net app + couchbase Lite: each application has a registered sync gateway user, with access to one channel.
    – Server application:
  • .net app + couchbase SDK: I’m using this to read documents, and insert documents i want to sync to the client.
    Until now it seems all is working, I’ve a few questions, but the basic one is:
    Am i using the right couchbase component chain/tools for my purpose? Suggestions?

Thank you for help!

2

Looks good, just be aware that your “logged documents” are a bit trickier to implement correctly due to the deletion. Couchbase Mobile is very replication-centric, so when you delete a document, it doesn’t literally delete it — the deletion has to be replicated to the client, so deletion really just adds a new revision that’s marked as deleted (also called a “tombstone”.)

To really delete the document on the client and free up its storage space, you’ll want to use the database’s purge method instead of delete. Purging a document removes all trace of it from the local db.

The trick is that you also have to make sure that the document once replicated to the server isn’t visible to the client. Otherwise the pull replicator may pull that document back to the client after it’s been purged, since the replicator will see that it doesn’t exist locally and decide that it’s new and needs to be downloaded. So you’ll want to set up your sync function and channels so that these documents aren’t added to channels visible to the client.

3

Thank you for information!
So, speaking about the logged documents, a correct strategy could be:
Mobile/Client side:

  • Build a logged document with the property “syncmode” : “downloadonly”
  • Push the document
  • Check using a Rest call that the server has the document (to be shure the Push have worked)
  • Purge the document
    Sync Gateway side:
  • Write a sync function that returns before assigning the logged document to any channel, something like:
    if(doc.syncmode == “downloadonly”) {
    return;
    }

May it be a good strategy?

4

Yes, that sounds good to me.