2

I've read a lot of articles about having a datastore per microservice. I'm going to use this approach but want to know the best way to go about it using Couchbase Sync Gateway since I want to use Sync Gateway REST API calls both from mobile AND backend server apps. I am thinking that the simplest way to go about this is to have one Couchbase cluster (3-n Couchbase Server instances) with maybe 2-3 buckets. A bucket for sessions maybe, another for all of my data, and maybe some others later. For each microservice's "database", instead of having different physical clusters for each, I'm thinking I should just put all of the data in one bucket and differentiate the databases and tables by document fields. So maybe I would have something like:

{
  database: 'person-api'
  doc_type: 'Person'

  ...
}

I would also have multiple database entries for each service all pointing to the same bucket in my sync-gateway config file. Then I would need to set up ACLs or some kind of controls that would only allow the backend server applications to access their own databases (so the 'election-api' server could only read/write docs with the corresponding database property). This would all have to be through Sync Gateway, for writes at least (I might do most reads using the sdks instead).

Sync Gateway is still a bit confusing to me and I'm not sure if this is the best approach. Would I just use channels as a sort of ACL? Is this just a bad approach to begin with? Any suggestions? thanks!

gcc
  • 283
  • 1
  • 3
  • 14

1 Answers1

-1

So in Sync Gateway you have the concept of CHANNELS , JSON Docs & USERS.

In the micro service model you probably want to separate data into different parts when:

  • You want to use a specific sub-set of data in the future for other
    projects.
  • You may want that data to have a sync function for a specific purpose.
  • You might want to keep things simple and you do not want to manage a very large and complicated sync function to manage all the data types.

  • You have very specific security concerns. So have one sync gateway database for public information and a second one for very private/sensitive data.