On Wednesday, June 11, 2014 5:18:29 PM UTC-7, ingenthr wrote: > > From: J Anderson <jch...@couchbase.com> > Reply-To: "mobile-couchbase@googlegroups.com" < > mobile-couchbase@googlegroups.com> > Date: Wednesday, June 11, 2014 at 6:50 PM > To: "mobile-couchbase@googlegroups.com" <mobile-couchbase@googlegroups.com > > > Subject: Re: Mobile App + Web App > > Just use the REST API, it is less moving pieces. I am just now adding a > note to the Bucket Shadowing documentation: > > Bucket shadowing is meant to enable sync for existing Couchbase Server > apps. If you are creating a new app with both mobile and web clients, we > recommend starting by connecting via the Sync Gateway REST APIs > <http://developer.couchbase.com/mobile/develop/references/couchbase-lite/rest-api/index.html>, > > and to add backend services use the Changes Worker Pattern > <https://github.com/couchbase/sync_gateway/wiki/Changes-Worker-Pattern>. > > > > Chris: I understand why you say this, but adding pieces to our mobile > documentation effectively saying that programming against Couchbase should > be done with Sync Gateway REST if doing mobile and web points to a real > problem. I don’t think it’s accurate to say that the Sync Gateway REST > interface defines how to program against the system going into the future. > > I think we'll always need to make it possible to connect as a peer would and interact via the Gateway like that. We're lucky that it translates well to REST. In the future we want to do whatever the best thing is. I hope that includes all the power of N1QL and ease of use of the SDKs. But for now it's a step I would avoid on a greenfield app as it introduces complexity that you can always add later if you decide you need Couchbase Server style access.
> Rather, that’s a can we’ve kicked down the road. > > And by the way, I’m not at all religious or defensive about this given > my history with the SDKs. I just worry that we now have three shipping > models of programming the system and N1QL will add a fourth > <http://hub.internal.couchbase.com/confluence/display/cbeng/Couchbase%27s+Many+Faces>. > > I’d be glad to make changes to converge as I indicated before we went to > ship our mobile 1.0’s. > > I think we’ll need to address this in the field on a case by case basis… > There are certainly cases where bucket shadowing is the preferred approach. Anytime you have a read write workload that is super high velocity, where you'd be driven to Couchbase Server performance etc, bucket shadowing can help because it's async processing by the sync function can be a better model. So for many apps that already rely on Couchbase Server, bucket shadowing is a good way to get started. If you are doing a mobile-first app I'd suggest just sticking to the minimum surface area possible right now. To me that means if you just need to watch for events and change documents sometimes the REST API is a great fit and not much of a learning curve. I sent you a mail about an idea for providing Smart Client direct access to the Gateway. Chris > > > > -- > Matt Ingenthron - Director, Developer Solutions > Couchbase, Inc. > -- You received this message because you are subscribed to the Google Groups "Couchbase Mobile" group. To unsubscribe from this group and stop receiving emails from it, send an email to mobile-couchbase+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/e014faa7-85e9-43d7-b382-eef1fd9c9bca%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
