Web + Mobile Shared RBAC

Mobile Sync Gateway
1

Hello everyone.
I’m developing, with some friends, a fairly complex software that provides services for companies and requires a strong layer of security, because every subscribed company has a lot of roles: admins, employers ecc. ecc.
I need an example of Couchbase infrastructure for this particular use case:

1 - I need the mobile offline synchronization
2 - I need vertical and horizontal replication across multiple servers.
3. I need a browser version of the product, in addition to the mobile.
4. I need a centralized RBAC, so that permissions for the mobile are also complied with by the browser.
5. I need speed.

The infrastructure that I had tried to use was Couchbase Server + Sync Gateway, but I found the following problems:
1 - If you use Sync Gateway only for the mobile and Couchbase Server only for the web application, you have the speed but you do not have instead the web site RBAC.
2 - If you do the CRUD operations for the web through the Sync Gateway RESTful APIs, you have RBAC on the web side but you have the following problems:
1 - To update and delete you have to use the revision_id
2 - You lose in speed, because as I noted CouchNode (I use Node.js as a server-side language), is much faster than HTTP.

Can anyone recommend a new idea of infrastructure using Couchbase Server and Couchbase Sync Gateway?

2

1 - If you use Sync Gateway only for the mobile and Couchbase Server only for the web application, you have the speed but you do not have instead the web site RBAC.

You will also need to use Bucket Shadowing to keep the Sync Gateway bucket from getting corrupted, which adds complexity.

1 - To update and delete you have to use the revision_id

This shouldn’t be that hard. What’s the issue you are running into? (just makes your code more complicated?)

2 - You lose in speed, because as I noted CouchNode (I use Node.js as a server-side language), is much faster than HTTP.

True, the memcached protocol that is used by the client SDK’s is more efficient than HTTP. With HTTP2 around the corner, this gap may narrow quite a bit.

Can you be more specific regarding the speed issues you are seeing? How may ops / sec are you trying to run?