Hi Freddy, you are pushing for a feature that I think would fall into a category that earlier discussions on this list pushed aside to a separate list, [email protected] I would asume it to be a ' "no-go" for design of philosophical reasons' as you put it based on these discussions. However it can be done, I did it this way
-- the _rewrite interface of the new release let you define rewrite rules as javascripts functions (make your own API server if you like) http://docs.couchdb.org/en/1.6.1/api/ddoc/rewrites.html <http://docs.couchdb.org/en/1.6.1/api/ddoc/rewrites.html> -- your own api can include calls to other endpoints http://docs.couchdb.org/en/1.6.1/config/http-handlers.html#global-http-handlers <http://docs.couchdb.org/en/1.6.1/config/http-handlers.html#global-http-handlers> and include thinks like the users IP address, user id etc -- OS Daemons http://docs.couchdb.org/en/1.6.1/config/externals.html <http://docs.couchdb.org/en/1.6.1/config/externals.html> keep a node.js running in the background that can do anything you want -- procedures or recipies for what to do, you can store as JSON in the database -- these procedures can be promise chains that call your CouchDB several times to compose e.g. a report or perform a batch job, do things like extrenal content scraping or lookups before calling your message service to deliver the report nicely wrapped in a html template. -- your triggers can be acted on by a daemon looking at _changes http://docs.couchdb.org/en/1.6.1/api/database/changes.html <http://docs.couchdb.org/en/1.6.1/api/database/changes.html> So this way you can customize the frontend and the backend to fit your needs. By making the node.js daemon very general and keeping all the variable stuff as JSON data, the node.js installation can go with your standard server image and you have your entire system on one platform, CouchDB, which is extremely convenient given its replication functionality. br johs PS I recommend this tool for design document programming: http://ddoc.me/ <http://ddoc.me/> > On 19. mai 2016, at 13.49, Reddy B. <[email protected]> wrote: > > Hi, > > I am fairly new to CouchDb and loving it so far. I think this database is > shockingly underated. I love the "Relax" approach and the design choices > that have been done, and I hope things will continue with the same philosophy. > > I couldn't find if this has been discussed before but I was thinking that it > would be extremely cool to be able to setup triggers that POST arbitrary json > to arbitrary endpoints. I think this would be a killer feature if there was > built-in support for that - and seems to fit well with the HTTP approach of > couch. > > So basically, this would be about allowing us to add an arbitrary number of > triggers to any view. Each trigger would be called only if the view emitted > "something" and the trigger would receive the document passed as a parameter > to the view (this is to take advantage of the update frequency of views) Then > in terms of posting, there could be a new built-in javascript function > calling curl behind the scenes which can be called from the triggers. > > For the same purpose, it would be interesting to introduce configuration > documents at the database level whose properties could be accessed from these > triggers (I'm thinking of situations when one would need to call a different > URL when in testing, staging, production etc...) > > In terms of use case, this would allow us to do things as diverse as sending > email notifications, and maintenance tasks. More generally, this would > eliminate the need for most of the maintenance jobs out there while making > these systems much more efficient by removing the need to run jobs at > arbitrary times even when this is not necessary. Also, since most web > frameworks are asynchronous and process each request in a different thread, > this would be a way to easily parallelize certain operations. > > I just wanted to know if there was any chance to see this come out one day or > if this would be a "no-go" for design of philosophical reasons. > > Cheers, > > Reddy >
