Cloudant would have to consider whether or not to support such a thing. It 
wouldn't be automatic just because it lands in couchdb. 

We'd at least have to think about rate limiting as well as good tooling for 
customers and operators if we wanted to support automatic outbound triggers of 
some form. 

Passing no judgement on the proposal, just saying there's additional thought 
around providing this appropriately in a service context at scale. 

Sent from my iPhone

> On 27 May 2016, at 08:41, Nuno Cruces <ncru...@gmail.com> wrote:
> 
> Hi,
> 
> Sorry to cross post over couch-app, was unsure where the discussion was
> going to continue.
> 
> I think this would be cool, if for no other reason so that one day Cloudant
> (or a similar CouchDB based DBaaS) could trigger mobile push notifications.
> 
> It's one of those tidbits that prevents a two-tier architecture from
> working for a mobile app.
> 
> Cloudant now gets me through 95% of the way, but an app server is needed
> for these bits, and that needs to be managed, scaled, kept up to date, etc.
> 
> Regards,
> 
> Nuno Cruces
> 
>> On 2016-05-25 16:00, Reddy B. <redd...@live.fr> wrote:
>> Wow shame on me, many apologizes for the delay in my reply.
>> @Harry
>> Thanks a lot for the pointer, I didn't know that I was able to hook into
> the datbase-change event, I definitely need to read more about the changes
> API, this is an interesting way to look at the problem.
>> The reason I wanted to use curl was to send a request to an external
> endpoint. Let's say, server A is the application server, and couch is on
> server B. When a certain type of change is made to a certain type of
> document, I want a certain POST request to be made to a certain server C
> who will know what to do with it - to keep couch focused on data. I'm
> thinking of a situation where there are a number of servers both in the
> application and the database layer (but only the fact that there would be a
> number of servers in the application layer, some of them having a specific
> purpose is relevant here).
>> I thought it could be interesting that Couchdb be directly able to do
> that, so that provisioning database servers is easier since there would
> only be CouchDb to install, and replication would allow to share the
> "script" containing the database call to be made easily between servers.
>> However if I need to poll the changes feed, I guess I'm back to square
> one since my objective was to avoid polling. But here I will need to look
> at the documentation first :)
>> @Johs
>> Thanks a lot for sharing this, this is gold !Even though I'm using
> CouchDb in a 3-tiers infrastructure (we're not ready for couchapps - yet !
> - as a business), and I don't like mixing concerns and putting application
> logic in the database - things like POST triggers are as far I'm ready to
> go - for now :) -I can see that besides these details there are two bottom
> lines in what you say : either enhancing the CouchDb API to fit my needs,
> or running an OS daemon and keeping the configuration stuff as JSON to take
> advantage of the replication features of Couch (hopefully I understood your
> point properly).
>> The first one seems like an overkill I'm afraid considering my modest
> needs, and the second one takes me back to polling the changes feed (the
> point it to avoid polling) and making node provisioning a bit more
> difficult :/ (But besides that, you opened my eyes on possibilites for
> other matters that I find really cool). I'll keep studying this 2nd point:
> if I can reuse this Node.js thing for other purposes and end up with only
> CouchDb + Node.js in an image to suit all my needs, it might be worth it !
> (But while the need doesn't go beyond these triggers, I think it would make
> the architecture overly complex to win almost nothing and I'd probably
> better stick to background jobs in the application layer).
>> Thanks again for these ideas !
>> @Jan
>> Thanks a lot Jan, this looks intriguing but extremely cool. I'm not sure
> it would help me on this particular issue based on what I said previously
> but it definitely opens up some perspectives, and help approach this class
> of problems from a different perspective.

Reply via email to