Mobile App + Web App

[Francisco Garcia]

I am interested in using CouchBase as backend for a mobile app (CBL iOS) with also a web version (Ruby)

As far as I have explored so far, it looks like CouchBase Ruby SDK is not "gateway aware" and deals with different versioning. 

Because of the versioning and authentication issues, it seems that once an app works through the gateway (mobile), anything else (web app) must go through the same channel.

Although the Gateway API looks a lot like the one of CouchDB, I am having many problems to make the standard Ruby CouchDB gem (CouchRest) work with the Gateway.

If I intend to develop a web app that uses the Gateway. What should I expect? I imagine two cases:

1. CouchBase will release a Gateway-Ruby-SDK

2. The gateway will behave more like CouchDB to make third party libraries more reusable.

What should I plan for?

I am having several issues making CouchRest use the gateway as a replacement of CouchDB. Most of them seems easy to fix by myself, but I am curious to know which one is the current future outlook and support for cases like mine

If there is any interest, I am willing to contribute documenting better my discoveries.

[Jens Alfke]

On Jan 28, 2014, at 5:01 AM, Francisco Garcia <pub...@francisco-garcia.net> wrote:

1. CouchBase will release a Gateway-Ruby-SDK

I don't think we are going to release our own SDKs for the Gateway REST API.

2. The gateway will behave more like CouchDB to make third party libraries more reusable.

Sure, if there are incompatibilities that make a CouchDB library unusable, I'd like to fix them. Please file an issue describing the specific incompatibility.

Another possibility is to use the new 'bucket shadowing' feature which was added after beta 2. This lets the gateway sync with another Couchbase bucket. You can read and write that bucket normally using Couchbase SDKs.

—Jens

[Charlie Woloszynski]

I am very interested to hear your discoveries.  I am also interested in supporting both a mobile app as well as a Web app, all backed by Couchbase.  

My goal, as I suspect is yours, is to provide access to the data in the Couchbase from anywhere, PC or mobile device, with either a web app or a mobile app.  Seems like something that most CouchBase users will need to support as their solution develops.

[Cristian Monterroza]

Hello all,

Has anyone else from the community experimented with getting a Ruby web app working with a Gateway instance? 

 

-- 
Cristian Monterroza

--
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-couchba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/b90d1ae7-85ce-4eb1-9fe1-f203f1ebc184%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[CouchbaseLover]

We are actually working on it right now with shadowing as Snej mentioned,what problem we have so far is with attachment/user management and that they are in sync. But we can create a documents from the web interface that's used then used seamlessly in iOS (why this mostly works is because of shadowing).

[CouchbaseLover]

We are working with RoR also, we tried to implement ElasticSearch but that was a disaster with a lot being deprecated.

CouchbaseLover

[Cristian Monterroza]

CouchbaseLover, 

You just surfaced my next question: User Authentication. If you are working on RoRs, then you are most likely familiar with ActiveRecord and dealing with the Users table. What I gather so far is that: 

1. SyncGateway handles the lack of metadata from the Web app side transparently. 
1. Web app talks to the regular bucket. 
2. Couchbase Lite clients deal with the “shadow bucket."

The most relevant example that I found regarding the WebApp side is this blog post: 

http://blog.couchbase.com/ruby-rails-and-couchbase-model-social-application

However, in that example it shows how to authenticate via twitter and it does NOT concern SyncGateway. Are there any equivalent CBL / SyncGateway tutorials out there? I’m interested in knowing what others have tried before I get hacking. I’m particularly interested in this scenario: 

• Clean Couchbase Server (CBS) and SyncGateway (SGW) installation. 
• This means properly setup SGW with Bucket Shadowing Enabled. 
• The first interaction a user has is with the Ruby WebApp.
• A user account is created, some docs are generated and synced between Buckets.
• A user gets a mobile app and has data available to him/her. 
• Couchbase Lite iOS or Java, etc. native client.

If anyone is interested in talking in depth about this maybe we should create a CBL meet-up. I’m around 6th and Market (in San Francisco) if anyone wants to code and/or grab a drink. 

-- 
Cristian Monterroza

cmont...@wrkstrm.me
Sent with Airmail

To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/7eff8029-6f22-46bb-9638-d2c624175933%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[J. Chris Anderson]

On Tuesday, June 10, 2014 11:45:08 PM UTC-7, Cristian Monterroza wrote:

 

Are there any equivalent CBL / SyncGateway tutorials out there? I’m interested in knowing what others have tried before I get hacking. I’m particularly interested in this scenario: 

• Clean Couchbase Server (CBS) and SyncGateway (SGW) installation. 
• This means properly setup SGW with Bucket Shadowing Enabled. 
• The first interaction a user has is with the Ruby WebApp.
• A user account is created, some docs are generated and synced between Buckets.
• A user gets a mobile app and has data available to him/her. 
• Couchbase Lite iOS or Java, etc. native client.

This is a great use case. It's been years since I wrote Rails but I used to know it well. I guess along our current line of development that would involve building an open-source Rails app like you describe, targeted at serving the schema we use in ToDo Lite. 

 

If anyone is interested in talking in depth about this maybe we should create a CBL meet-up. I’m around 6th and Market (in San Francisco) if anyone wants to code and/or grab a drink. 

The mobile team often works out of your part of town. I'm sure we'd be happy to host a meet-up. Maybe we can bring in the Double to allow remote folks to participate.

Chris

 

To unsubscribe from this group and stop receiving emails from it, send an email to mobile-couchbase+unsubscribe@googlegroups.com.

[Cristian Monterroza]

Chris, 

I saw your other comment to Sandra earlier today. The sample project I’m thinking of would be targeted at getting ToDo Lite to sync to a web client. Would you recommend trying to code this with the REST API or Bucket Shadowing? 

Thanks,

-- 
Cristian Monterroza
Sent with Airmail

To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/394e6326-6184-4ac9-9a1f-aade18f085e5%40googlegroups.com.

[Jens Alfke]

On Jun 10, 2014, at 11:45 PM, Cristian Monterroza <cmont...@wrkstrm.me> wrote:

• The first interaction a user has is with the Ruby WebApp.
• A user account is created, some docs are generated and synced between Buckets.
• A user gets a mobile app and has data available to him/her. 
• Couchbase Lite iOS or Java, etc. native client.

This is a case of custom authentication. The workflow looks like this:

1. Mobile app sends a special login request to your web-app
2. Web-app authenticates the user’s credentials
3. Web-app creates a user account on the Gateway if this is the user’s first login
4. Web-app POSTs to the Sync Gateway’s _session endpoint to generate a Gateway session for the user
5. Web-app returns the session cookie string to the mobile app
6. Mobile app registers the cookie with the replication object(s) by calling the setCookie method
7. CBL replicator sends the cookie with its requests, which authenticates it to the Gateway

I think Traun wrote a post about this a month or two ago including a great network diagram showing the flow of messages.

—Jens

[J. Chris Anderson]

On Wednesday, June 11, 2014 1:26:47 PM UTC-7, Cristian Monterroza wrote:

Chris, 

I saw your other comment to Sandra earlier today. The sample project I’m thinking of would be targeted at getting ToDo Lite to sync to a web client. Would you recommend trying to code this with the REST API or Bucket Shadowing? 

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, and to add backend services use the Changes Worker Pattern.

 

[Cristian Monterroza]

Jens & Chris, 

Found the diagram: 

http://cl.ly/image/0J3D0x141z2q/o

Also the conversation in case anyone searches for this (Although they should be going to the official documentation). 

https://groups.google.com/forum/?hl=en#!search/Cookie$20Auth$20Question/mobile-couchbase/V7tsRELr_NM/fuzn9OYt0IIJ

-- 
Cristian Monterroza
Sent with Airmail

To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/cc797ea0-9d3e-4bc3-93da-140c4e05513e%40googlegroups.com.

[Matt Ingenthron]

From: J Anderson <jch...@couchbase.com>
Reply-To: "mobile-c...@googlegroups.com" <mobile-c...@googlegroups.com>
Date: Wednesday, June 11, 2014 at 6:50 PM
To: "mobile-c...@googlegroups.com" <mobile-c...@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, and to add backend services use the 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.

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.  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…

-- 

Matt Ingenthron - Director, Developer Solutions

Couchbase, Inc.

[Matt Ingenthron]

All,

My apologies.  That was meant to be a reply to J. Chris, as you can probably tell.  I’d typed it up in a forward and then a too-quick decision to put it in a “reply” did the wrong thing.

It’s clearly stuff we’re discussing amongst folks here at Couchbase and we’re working on moving to the right place!

Sorry for the noise,

Matt

-- 

Matt Ingenthron

Couchbase, Inc.

[J. Chris Anderson]

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, and to add backend services use the 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.  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

[Francois Louis]

Hi Jens this was very useful for me, wasn't sure whether to make a new post for my question.  I'm a bit new to all this and have a GUEST application working with couchbase lite and it works great.  I am now considering the login/authentication part to the app but not sure where to start.

I would like to use as much 'read-made' functionality as possible as my dev horizon is quite short.  I liked the idea of using Persona but wanted the signup process to take place completely within the app (i understand with persona that the user has to redirect to the Persona website to sign up).  Is it possible to use something like 'parse.com' where ready-made ios classes exist to handle signup and signin, and then direct it to sync gateway somehow to generate session cookies .. ?  Sorry if this doesn't make too much sense but am a bit lost on this side of things currently !!

Many thanks, Francis.

[Jens Alfke]

On Sep 2, 2014, at 3:00 PM, Francois Louis <louisfra...@gmail.com> wrote:

I liked the idea of using Persona but wanted the signup process to take place completely within the app (i understand with persona that the user has to redirect to the Persona website to sign up).

The iOS Persona SDK pops up that web page in a view, so the user never leaves the app. It's pretty smooth. I don't think there is an equivalent for Android, though.

 Is it possible to use something like 'parse.com' where ready-made ios classes exist to handle signup and signin, and then direct it to sync gateway somehow to generate session cookies .. ?

No, we don't have anything like that yet. Sorry.

—Jens

[Francois Louis]

Thanks for that Jens, I will look at Persona in iOS more closely. Have a great day, Francis.