Couchbase Lite from desktop browser (REST API)

Hi All,

I would like to develop a web application for desktops and I would like to be able to connect it to either Couchbase Server or Couchbase Lite.

I think it is pretty simple to connect to Couchbase Server but I am wondering if it is possible to point the web app to a local Couchbase Lite install and use the REST API

Everything I read seems to revolve around PhoneGap. The Couchbase Mobile stack really sounds like it would suit me. Eventually I want to develop a Web App for use in Desktop Browsers, a desktop app developed in NodeJS and Electron and more basic mobile apps.

I’m thinking of sharing the code so the desktop web app would connect to Couchbase Server and if installed a local Couchbase Lite install via the REST API. The Electron app would connect to Couchbase Lite via REST API.

Or am I just reading everything wrong.

1 Like

You can. Do you have a basic idea of architecture? like a diagram

Here is what I want to do.

  1. Desktop Browser talking directly to Couchbase Server (Or would it be Sync Gateway) (Windows/xOS)
  2. Desktop Browser talking to a local install of Couchbase Lite (Windows/xOS)
  3. Desktop Electron application talking to a local install of Couchbase Lite (Windows/xOS)

I was hoping to only write the one set of code to deal with the database. I thought if I used the REST API then common code would be a possibility.

I know I could use PouchDB but if I can sidestep that and use only Couchbase that would be great.

It seems to me that the Couchbase Mobile stack is a useful stack for the Desktop but doesn’t appear to be documented very well if it can in fact be used like that.

to Sync Gateway. Having it talk to a local CBL would be easier and let CBL take care of sync

:+1: … test out the .NET version it should work for you.

PouchDB works 100% with SG but CBL has things like compression of data to/from SG , live database event listeners , …etc . Using CBL will future proof your build as they are designed to work together. and of course its open source so you have options for what fits your needs as far as business critical app needing support.

There are people who do use it as an all-in-one data distribution and delivery method, people who see the “Big Picture” of CB Mobile. Other are very project focused and wanting CB Mobile to handle a specific need. What specific things are you looking for on the desktop side?

I would prefer to use a local CBL

We are developing an offline capable Web app. I initially was going to use PouchDB in the Browser as it was easy to do. Having read up on CBL this would do the job better but I’m not sure it is easy to integrate in a WEB Page like PouchDB.

  1. Can CBL be installed from a web page?
  2. Is there a version of CBL that will install on Mac and Windows.

Are there any examples of how to access CBL from JS?

1 Like

Hi John,

We are pursuing a similar thought process and I’m curious if you reached a direction following this line of questions?


We are pursuing this too. There is simple no information on how to use CBL with an Webapp like e.g. angular.

Can CBL be installed from a web page?

No. Couchbase Lite is a native library. You can use it in PhoneGap or other apps that package HTML/JS sites into native apps, but not from a regular web page. If that’s what you need, look at PouchDB.

Is there a version of CBL that will install on Mac and Windows.

Yes, if you look at the download page there is a Mac version. And the .NET version can run on Windows (right @borrrden ?)

I’ve been in a similar position and there’s basically no choice but to go with PouchDB. It works since both PouchDB and Couchbase Sync Gateway are based on the CouchDB replication protocol.

There’s a big downside though, mostly performance when dealing with bulk documents — CBSG send a ‘Content-Type’ header which is not compatibile with PouchDB which means it falls back to fetching each document seperately. It can be noticibly very slow for initial sync or any bulk changes. Excessive network chatter is really noticable on mobile browsers too. You also miss out on n1ql queries which really sucks.

My understanding is there’s been a lack of communication between the projects which have resulted in a less than desireable state, but hey, at least it works to some degree.

Make up your own mind if it’s worth it (I’ve decided on using it as an intrum solution). I’m hoping with WebAsembly getting closer we may see a port of CB lite core to WebAsembly… or hey, we may have some fixes in PouchDB…

Here’s a list of related issues in PouchDB:

(have to break up my links as there’s a 2 link limit for new users on this forum, sorry)

With PWAs (progressive web apps) and “offline first” slowly becoming more prvelent I hope CB give this area some much needed attention. There’s no out-of-the-box solutions which work well so work in this area could potencially lead to huge adoption of CB as the defacto leader in the web PWA/offline space.

I have a similar question so I’ll ask here:

We have a mobile app and considering building a web app too. The web app will be using c# / Considering we’ll have many users signed in at once on the web app what’s the best way to sync data between the Web app (server side) and couchbase?

(We won’t be storing data or have significantly app code on the client - app will not function offline)

So far I can see two options:

1 - create our own basic sync on the server using a SG listener to populate tables in a relational DB and push data changes from the relational DB back to CB via the SG

2 - have a replication going on the server for each signed in user. Effectively using CBL to replicate user data on separate SQLite dbs one for each user. Of course there will be some sort of data management / caching required for this

Any advice / suggestions / views on what is best to do?


Why not just use Couchbase as the database for the web-app? Then it and mobile can share the same data, problem solved.

Hi Jens,

a few reasons:

  • i was under the impression all doc updates/ insertions have to go through the SG. Isn’t that the case? If so, using CB purely as the read-only database offers little benefit

  • currently indexing is not enabled on our cluster (which I assume is needed for querying?). This was done to ensure we don’t run into unforeseen issues when the cluster was first deployed.

  • Our mobile app really depends on CB+SG working flawlessly (which has been for a few years now). Ensuring we don’t introduce any instabilities by accessing data directly in CB from the web app is a priority. Obviously there is a bit of extra dev time needed (sync) and some extra costs (secondary relational DB) but I don’t think they will be significant.


With Sync Gateway 2 you can create/update docs directly through Couchbase Server (at last!)

You’ll have to ask in a Server forum about indexing … I don’t think it’ll cause any issues, other than increasing the load on the db server slightly as the indexer runs.

Obviously there is a bit of extra dev time needed (sync)

In my experience (I’ve implemented three replicators by now), sync is a thing that seems pretty easy until you actually implement it… Getting the details right is really tricky.

Thanks that’s actually very helpful.

Is there a doc I can use as reference if I decide to implement sync? I’m thinking of having a read (if there is one) as it may help make up my mind.

Otherwise I’ll just go through the C#/Java CB Lite code and use that as reference.

So many choices :slight_smile:

No, sync is not a topic which can be documented in any sort of meaningful way for a general case. You also will not gain a majority of the information by looking at CBLite code since a lot of the logic is implemented at the C++ level. The C# / Java implementations basically only provide some help on top of that for stuff like opening a connection (in particular, with TLS) and resolving an incoming conflict.

I see, thanks for info @borrrden!

I know where to look now.

To do quick-and-dirty sync with SG, you just use its REST API. Pulling is done using the changes feed, and pushing is done with PUTs.

Thank you! I was planning on doing something very basic along these lines.