Clarification w/ Couchbase Server and Sync Gateway (Do I need Couchbase Server?)

Mobile
1

I believe I understand what’s going on, but my understanding an a coworker’s is different, so I’m still not 100%-- just looking for clarification. I’m going to write my understanding, and if anybody has some time if they could point out any misconceptions, or expand on anything, that would be amazing help :slight_smile:

Sync Gateway is a RESTful server (takes requests, returns responses), that wraps a non-relational database and keeps track of the latest version of documents

We have a native app that needs to keep data synchronized between users, so at the very least we need to have Sync Gateway running, so that the users can GET latest documents, and POST changes to documents

It appears the main thing about Sync Gateway is that the Couchbase Mobile Framework has built-in “Replication” functionality that interfaces with Sync Gateway, that automatically handles the GET/POST requests and subsequent responses.
It is unclear whether or not we can manually create the GET/POST requests, and bypass the Couchbase Mobile Framework

Couchbase Server is another RESTful server, that you can definitely manually create GET/POST requests (“Queries”), and then Couchbase Server has to be connected to a Sync Gateway, similarly how Couchbase Mobile connects to one.

So you create a Query to Couchbase Server, it will make a GET/POST request to Sync Gateway, and then Couchabase Server will create a response from that.

It appears the reason why you’d want Couchbase Server is to utilize the web portal to view and modify the data directly, as well as if you had a Web application that needed access to the Sync Gateway data (Because you can’t compile Couchbase Mobile and it’s Replication logic into a Web Application), as well as some additional security?

Though Sync Gateway already seems to have some security baked in, with user accounts

The only thing that is unclear is the concept of buckets in Couchbase Server

But all things considered here, if we just have a native application synchronizing data across users, do we even need to run Couchbase Server?

2

Would recommend reviewing our documentation on server , buckets and mobile. The answers to your questions are all there.

What do you mean by “Couchbase Mobile Framework” ? Couchbase Lite ? You can directly call the REST APIs but you will have to implement replication and local client side storage. Why are you looking to bypass that (Whats your client platform? )

What do you mean by “native application” (native to what platform?). Yes, you need couchbase server as backing persistent store for Sync Gateway (there is a “walrus mode” only meant for development purposes)

1 Like
3

Hi Priya,
Thanks for your time

Embarrassingly, I have reviewed all the documentation, took notes, etc. but the main issue is that my entire career has always been in front-end client development, so a lot of the documentation is too dense for me to understand, as I don’t have enough domain knowledge to understand some of the concepts which aren’t explained simply enough for me

Yes by Couchbase Mobile Framework, I meant Couchbase Lite
I’m not looking to bypass the framework, I was just clarifying my understanding of how the client/framework interfaces with Sync Gateway

Sorry by native application, I meant a macOS desktop application

So I actually got data synchronization to work with only Sync Gateway running. All of my clients are hitting it, but based on your answer here, I’m assuming that if I were to turn off walrus mode, it wouldn’t work?

This is what the documentation says about Walrus mode:
“…in-memory server called “Walrus” that can withstand most prototyping use cases, extending support to at most one or two users”

But I don’t understand what Walrus mode is offering me, and why I shouldn’t be using it in production?

So based off of your explanation, Couchbase Server is the daemon that wraps the actual non-relational database I want to use?

My Clients will make RESTful requests to Sync Gateway via Couchbase Lite,
Sync Gateway communicates via localhost to Couchbase Server, to update the database and query the database?

I just want to make sure I do things right, especially considering I somehow magically got things working without feeling like I fully understand it

4

Yes- it is a memory-only option so your documents aren’t getting persisted in the cloud. It is not scalable and it doesn’t go through QA testing process so no guarantees on its performance . You also don’t get features like High Availability that you would expect from a production grade system. @traun ?

Well- it’s more than a daemon. It is the server-side NoSQL data platform - is is distributed, scalable, performant ,built-in cache layer for high performance , includes a SQL-like query language, search , high availability and much more . You also have SDKs for almost all popular languages.

If you are using Couchbase Lite, you don’t have to use the REST API. The Sync Protocol will “magically” sync data between the Couchbase Lite clients and Sync Gateway (you just need to setup the replicator). The REST API is primarily used by web based apps that don’t have Couchbase Lite.

SGW communicates with Couchbase Server but it does not have to be “localhost”. In fact , in a real application, the CBS and SGW will likely be hosted on separate machines. The key is that She Gateway will talk to the Couchbase Server through interface defined in the “Sync Gateway config file”. There is a streaming protocol between SGW and Couchbase Server called DCP (if you are on 2.0)

I would strongly recommend that you walk through this tutorial as a starting point . It is for iOS but the concepts should apply for MacOS as well. At least check out the concepts that are discussed there . I think it’ss critical for you to understand whats going on so you can make an informed decision on your application architecture and deployment.

1 Like
5

Awesome, you’re very helpful, thank you!

The link is perfect, I will go through that tutorial, and I’m hopeful with what I know now, once I finish the tutorial I’ll know what’s going on

Another question, so Walrus is memory-only, but if I’m hosting my own server, and running SGW on it, then is there a problem?

I guess what I’m asking is, given my small scale (1000 client hard maximum), if I have them all replicate to a server I’m hosting myself, w/ SGW running on it, would this be a problem?

6

Only you can decide if there is actually a problem or not. Walrus is designed for prototype use and comes with no guarantees or support. If something goes wrong, it’s on you and the first thing people will tell you to do is “stop using walrus.” Furthermore, without careful setup, every time you restart Sync Gateway with walrus you will lose your data. Also, you can only hold as much data as can fit in memory. If you create too much, you will be sorry since there is nowhere to persist the data to.

Perhaps you are thinking that the sync is just transient data, that is gone once the sync is over. That is not the case. Everything you sync will get persisted so that later clients that connect can also receive the data. Thus as you use it more and more your data will grow. Couchbase Server is designed to keep the most active data in memory while putting the rest to disk. Walrus will not do this and will probably just die if it runs out of memory.

1 Like
7

Makes sense! Thanks for the knowledge :slight_smile:

8

@ayoh you definitely shouldn’t use Walrus in a production scenario, it’s not a supported configuration… it’s just there to get up and running quickly, and is used for testing.

You’ll be much better off running a single-node Couchbase Server node, but just remember to have an aggressive backup strategy since you’ll have no data replication.

9

Oh we’ll definitely need SGW

I think the confusion stemmed from thinking that SGW was backed by a database already, and that Walrus was just an option

But it seems like if you just use SGW, Walrus is all you get

I think It’ll be more clear once I run through the tutorial Priya linked