I’m really struggling with these proposals. I love the enthusiasm of everyone but I keep thinking we should rather simplify CouchDB. CouchDB is ultimately a database. One with excellent sync capabilities. And combining that with libraries like PouchDB and Hoodie make it an amazing database to build applications with. Adding routers and reverse proxies just makes it feel like we trying to push CouchDB into being more than it needs to be.
For example building Couchapp like functionality in Node.js is so simple and way better. Languages like Go also do that really well. Far superior than what we can do with a database. I would rather let the Node.js and Go web libraries serve content and let us focus on building a clustered replicating database. We will draw more people to this community if we can do that properly over creaky, slow and limited web serving mashed on top of a database. If I look at other popular databases, I don’t see any of them serving web content which is probably a sign that this idea is not something worth pursuing. However if there is a burning desire for this and developers raising their hands to code this functionality, I would not stand in your way. It is great to see the varied use of CouchDB out in the wild. Cheers Garren > On 19 Oct 2015, at 4:47 PM, Johs. E <j...@b2w.com> wrote: > > Thanks Andy, > I will try and get some use cases up on confluence. > As for whoever would pick up the work after ermouth, I have of course one > big thing on the wish list that goes well with a new router solution.. > reverse proxy > I remember asking about it when I first started to work w CouchDB and there > were some concerns regarding security. > Since then I think node.js has paved the way with content scraping and all > sorts of outgoing traffic. > > Has anyone work on a reverse proxy solution for Couch? > > johs > > >> On 18 Oct 2015, at 21:36, Andy Wenk <andyw...@apache.org> wrote: >> >> Hey Johs, >> >> thanks a lot for this. I need some time to dig into it. We need a place to >> write the user stories / use case down. So I suggest we find good place at >> the cwiki. So I suggest to use >> https://cwiki.apache.org/confluence/display/COUCHDB/Enhancement+Proposals . >> Do you have write access there? If not, please ping me. >> >> Great work! >> >> All the best >> >> Andy >> >> P.S.: Jan already mentioned the feature freeze. Please take it not as a >> demotivation but as the possibility to have a bit more time to work on it. >> >> On 17 October 2015 at 17:32, Johs Ensby <j...@b2w.com> wrote: >> >>> Andy, >>> I will make my first use case for function in _rewrite a high level one: >>> to create a standalone server that is an all-in-one DB server, application >>> server, api server and web server. >>> >>> I have played with the build of CouchDB 2 with rewrite function >>> implemented that ermouth put up on the irish AWS community AMI list and >>> the new use cases are endless. >>> First, I find that there are a few things that people fail to notice about >>> ddocs. >>> you need a tool to build a ddoc, editing JSON is not a viable option. The >>> Ddoc Lab of ermouth is in a class of its own. If you havent tried it yet, >>> do so from http://ddoc.me/ <http://ddoc.me/>. Installing on your own >>> couch it is as easy as storing the application, all included as one >>> document in any database. Ddoc Lab is a component oriented IDE with syntax >>> checking, less preprosessor and other build tools that let you keep a well >>> organized ddoc as a source project (in one couchdb document) and you >>> publich a ddoc to any target db. >>> with this tool you can organize your js modules and templates etc and >>> basically... >>> set up the API of your application in a ddoc. You can switch between >>> databases and their ddoc functionality based on username, role or >>> geolocation and limit access to parts of the Couch API as needed >>> >>> This is the method I would recommend to explore powerful simplicity with >>> function in rewrites >>> redirect port 80 directly to couch >>> set up 2 vhosts, one for public access pointing to youdb/_design/api and >>> one for sysadm pointing to / >>> for admin use Fauxton and Ddoc Lab on the sysadm vhost >>> you are set to develop great systems, no big tool stack to learn, just >>> bring in whatever js modules you like, the template engine you like, the >>> router you like, the HTML5 stuff you like.. >>> .. or just write some very compact js code in one place where you ealier >>> had to mess around with a whole stack of tools and systems >>> >>> below is the req object that the function takes >>> >>> Johs >>> >>> >>> >>> The rewrite function has this syntax >>> function(req) { >>> .. your code that will >>> return >>> path >>> // optional >>> headers >>> method // you can change this on the fly >>> code >>> body >>> } >>> >>> the function receives this req object >>> method >>> path >>> raw_path >>> query >>> headers >>> Accept >>> Accept-Encoding >>> Connection >>> Host >>> Upgrade-Insecure-Requests >>> User-Agent >>> x-couchdb-vhost-path >>> body >>> peer >>> cookie >>> userCtx >>> db >>> name >>> roles >>> secObj >>> >>>> On 1. okt. 2015, at 13.40, Andy Wenk <andyw...@apache.org> wrote: >>>> >>>> Johs, >>>> >>>> Yes for sure! That's always great. Maybe you can also write some user >>> stories (given when then) or scribble some graphics. Everything is useful >>> and will fasten the process ;-) >>>> >>>> Cheers >>>> >>>> Andy >>>> >>>> On 1 Oct 2015 12:38, "Johs Ensby" <j...@b2w.com <mailto:j...@b2w.com>> >>> wrote: >>>> Thanks for this Andy, >>>> >>>> I can contribute to the discussion of the feature seen from a user >>> perspective. >>>> Would it be appropriate to present some use cases? >>>> >>>> best >>>> Johs >>>> >>>>> On 1. okt. 2015, at 12.33, Andy Wenk <andyw...@apache.org <mailto: >>> andyw...@apache.org>> wrote: >>>>> >>>>> Johs, >>>>> >>>>> Let me please show the steps needed. >>>>> >>>>> * discuss the feature very clearly on the dev@. Please make sure that >>> core >>>>> developers as committers with commit bits are involved >>>>> >>>>> * code the feature. Make sure to implement tests >>>>> >>>>> * send a pull request and show it to dev@ >>>>> >>>>> * finally the community will accept or decline the feature (this will >>>>> involve refactoring and changes) >>>>> >>>>> As Alex said. The PMC or Jan do not decide about the feature. >>>>> >>>>> All the best >>>>> >>>>> Andy >>>>> On 1 Oct 2015 11:21, "Alexander Shorin" <kxe...@gmail.com <mailto: >>> kxe...@gmail.com>> wrote: >>>>> >>>>>> On Thu, Oct 1, 2015 at 12:07 PM, Johs Ensby <j...@b2w.com <mailto: >>> j...@b2w.com>> wrote: >>>>>>> will you welcome ermouths rewrite contribution? >>>>>> >>>>>> The decision is depends on the implementation. If it will be good, why >>>>>> not? Finally, CouchDB is open source project: we cannot forbid people >>>>>> right for contributions, we only welcome them. >>>>>> >>>>>>> Arguments against couchapps has to do with performance and the folly >>> in >>>>>> competing with node.js. >>>>>> >>>>>> Performance question for the new _rewrite implementation is very >>>>>> depends on query server. Once it can process this kind of functions, >>>>>> you may use something better than JS to gain better performance. That >>>>>> could be Erlang native query server, or luerl-based one, or else you >>>>>> like. >>>>>> >>>>>> -- >>>>>> ,,,^..^,,, >>>>>> >>>> >>> >>> >> >> >> -- >> Andy Wenk >> Hamburg - Germany >> RockIt! >> >> GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D 6BE3 9ED3 9588 >> >> https://people.apache.org/keys/committer/andywenk.asc >
