Peer to Peer in 2.0

72 views
Skip to first unread message

devlist

unread,
Apr 15, 2017, 11:35:42 AM4/15/17
to Couchbase Mobile
I understand there will be a new replication protocol in 2.0, that will not be compatible with 1.4 however to clarify...

Will multiple 2.0 couchbase lite clients be able to sync with each other without a sync gateway.
Using peer to peer discovery and replication.

Thanks,

Martin

Jens Alfke

unread,
Apr 15, 2017, 4:14:29 PM4/15/17
to mobile-c...@googlegroups.com

On Apr 15, 2017, at 8:35 AM, devlist <dev...@mac.com> wrote:

Will multiple 2.0 couchbase lite clients be able to sync with each other without a sync gateway.
Using peer to peer discovery and replication.

Yes; the new replication protocol actually makes this easier to implement because its design is symmetrical, so the ‘client’ and ‘server’ roles have the same implementation and use the same calls. (Unlike 1.x where the ‘server’ role requires linking in an HTTP server library to implement the REST API.)

Some of the code necessary for this isn’t in the current dev previews, but it’s scheduled for the 2.0 release.

—Jens

devlist

unread,
Apr 16, 2017, 7:57:38 AM4/16/17
to Couchbase Mobile
That’s great.

For our application we were also looking at using a browser to query (not sync) views and documents via the existing Couchbase Mobile REST API. This would allow offline browser access to the documents on the macOS CouchBase Lite client.
i.e. using a Mac as an offline document server? Then when the Mac is online it would sync via SG as normal.

If REST is removed will there be an public protocol or API to allow this in 2.0 ? (Just found a page from Jens about BLIP Over WebSockets)

Thanks,

Martin

Jens Alfke

unread,
Apr 16, 2017, 1:11:56 PM4/16/17
to mobile-c...@googlegroups.com

On Apr 16, 2017, at 4:57 AM, devlist <dev...@mac.com> wrote:

If REST is removed will there be an public protocol or API to allow this in 2.0 ? (Just found a page from Jens about BLIP Over WebSockets)

We’re still deciding what to do with the REST API. Everyone’s input is appreciated. Here’s a brain dump.

  • The Listener component (REST API) mostly gets used by PhoneGap apps.
  • For that, it would be more efficient to create a direct JavaScript binding for Couchbase Lite, than the current scheme that goes through XMLHTTPRequest and the Listener. It would also be easier for developers to use, and more consistent with our other language APIs.
  • On the other hand, there are other uses for the Listener, as you’re pointing out.
  • One of which is to provide a passive endpoint for the CouchDB replication protocol.
  • Also, our QA team points out that the REST API is a very effective tool for cross-platform functional testing of Couchbase Lite.
  • The Listener would need to be re-implemented at the LiteCore level, meaning we need to find a good cross-platform C++ embedded HTTP server library. (Currently I’m looking at civetweb.)

—Jens

James Nocentini

unread,
Apr 17, 2017, 9:45:32 AM4/17/17
to Couchbase Mobile

  • The Listener component (REST API) mostly gets used by PhoneGap apps.
  • For that, it would be more efficient to create a direct JavaScript binding for Couchbase Lite, than the current scheme that goes through XMLHTTPRequest and the Listener. It would also be easier for developers to use, and more consistent with our other language APIs.
I agree, the current approach of using the REST API to develop the data layer that's backing a user interface seems a bit unconventional. The big advantage it brings though is that in the case of PhoneGap, the app can be developed on a desktop browser first by sending requests to the Listener or the LiteServ utility app; making the "write code, run it" cycle a lot faster than deploying it to an emulator on every change. To achieve that with plugins, PhoneGap has a proxy API in which functionality can be stubbed so that when it runs on a desktop browser it won't fail (since the stubs replace the calls into the native API). So it should be possible to have the same ease of development with a PhoneGap plugin as with the REST API.

Regarding the development of a PhoneGap plugin, I don't think that a direct JavaScript binding for Couchbase Lite would be usable in the case of PhoneGap because it runs in the (mobile) browser. It would be usable for other frameworks like React Native (maybe NativeScript as well but I'm not sure). In other words, framework plugins are on a case by case basis.

For remote access to the database, it does make total sense to have a REST API but only for remote access. I think it's important to keep in mind the difference between the two use cases (app development vs. remote access). And if the REST API is indeed an adequate solution for remote access, to build out only the features that satisfy that use case (i.e 100% parity with the native API may not be needed in this case).

James

Todd Freese

unread,
Apr 19, 2017, 10:14:56 AM4/19/17
to Couchbase Mobile
Will SG 2.0 still support the REST API for data access as well as SG Views? We use them heavily to support a web client.

T

Jens Alfke

unread,
Apr 19, 2017, 9:24:19 PM4/19/17
to mobile-c...@googlegroups.com

On Apr 19, 2017, at 7:14 AM, Todd Freese <to...@filmworkers.com> wrote:

Will SG 2.0 still support the REST API for data access as well as SG Views? We use them heavily to support a web client.

I’m working on the implementation of the REST API right now, actually. The first priority is to get just enough stuff working (basic CRUD and _replicate) to enable automated testing — the QA team is very eager for that :)

No map/reduce views, though. How to expose the new query engine in a REST API is an open question. We can’t just let you post N1QL because we don’t have a parser for it. There’s an internal JSON syntax that we may expose; it’s not that bad once you get used to it. (You can see details in the couchbase-lite-core wiki.)

—Jens
Reply all
Reply to author
Forward
0 new messages