Couchbase questions

n1ql

#1

Hello. I’ve been interested in the server/sync gateway combination for a while now. It looks super easy to set up and develop with. I’ve looked at lots of examples, and while I do like the simplicity, there are some issues that seem handwaved around that I’d really like the answers to.

First, is there a solution for user creation/verification/password reset that doesn’t involve maintaining a separate server I’ve written myself? Sync Gateway seems to hand lots of this off to third-party services, which is fine unless someone doesn’t have an account on said services. Persona would have been an OK option if it wasn’t being shut down and didn’t have UX issues besides. I see there is username/password support but that users can’t be created outside of the admin API. I can of course hard-code users in the config file, which is a nice touch for development since inevitably one of the first things I do with a new database is create stock users with different roles.

It seems like the only solution is to front the gateway server with a thin proxy with a REST endpoint that creates users in the admin API. Is there no other way? I’m surprised that an otherwise self-contained solution doesn’t include some mechanism of user creation that is accessible to clients, even if it has to be selectively enabled. Or maybe there are other valid reasons to create a separate front-end proxy such that you aren’t maintaining code just to open up the account creation endpoint? Just seems like some of the advantages of Sync Gateway as a self-contained server go away if I’m suddenly maintaining my own front-end.

Next, I like the channels/authorization system. I have an app that I’ve toyed with porting from Meteor to Couchbase that very much depends on real-time functionality. It also has a complex workflow, and documents appear/disappear based on a number of factors. I have hundreds of lines of code in Meteor that handle these workflow transitions and document visibility. I imagine that would get compressed somewhat with channels, but the thought of maintaining all of that in a JSON config file just doesn’t look right. Is there some mechanism for maintaining code outside of the JSON config file and pulling it in? All of the examples I’ve seen just inline it, and when you have documents of various types changing visibility/availability based on their properties, that seems like it would get messy very quickly. :slightly_smiling:
Thanks.