Fwd: I work for Parse, would love to hear your thoughts on our new webhooks product

[Jeff Lindsay]

interesting email about recently announced parse webhooks... 

---------- Forwarded message ----------
From: Jeff Lindsay <prog...@gmail.com>
Date: Tue, Mar 31, 2015 at 7:55 PM
Subject: Re: I work for Parse, would love to hear your thoughts on our new webhooks product
To: Jamie Karraker <jkar...@fb.com>

Jamie,

Oddly today somebody else mentioned webhooks using return data not being a webhook. I picked the name webhook intentionally to frame the mechanism as useful beyond notifications. It's a hook like a callback. Callbacks are functions, they can have a return value.

This wiki, which is no longer authoritative, and has been reasonably overtaken by others, shows my early work evangelizing webhooks:

https://webhooks.pbworks.com/w/page/13385124/FrontPage

The third "use case" I pushed for was "plugins" in which you can use webhooks to alter application behavior. I was frustrated in the early days more people didn't do this. It turns out today though even less people do in relation to total implementers. But a popular example of people that do is Twilio. Github did too at some point. Other examples are applications that have since disappeared ... not because of webhooks just the natural way of things.

My guess is why it's not more commonly seen is the same reason people were afraid to do webhooks at all in the first place. It doesn't seem scalable. Today it's much easier with off the shelf background workers, queuing systems, etc, though all of that tooling does seem to push people in the direction of fire and forget hooks. But I think people are afraid to write synchronous webhooks for the same reason. But again, it *can* be done, at scale. Twilio is an example.

Do you mind if I forward this thread to the webhooks mailing list? 

-jeff

On Tue, Mar 31, 2015 at 5:08 PM, Jamie Karraker <jkar...@fb.com> wrote:

Hi Jeff, 

I’m a software engineer at Parse, and we just launched a webhooks product last week at F8 (http://blog.parse.com/2015/03/25/introducing-cloud-code-webhooks/). The idea is that instead of Parse running server-side hooks in javascript on our servers, we hit a url the developer provides to allow the developer to run custom code in any language on their own servers. Then we expect a response, with any updated data that we then incorporate into our normal save process. 

While this indeed seems like a traditional webhook, it is a little different in that it is not just a notification that something happened, but actually a two-way communication channel, where we actually expect something more than just a 200 response. I’m curious, have you seen something like this before? We spent a lot of time looking at previous webhook implementations, and every one that we found was used just as a channel to notify the developer of an event occurring, and never as a two way communication channel. Do you have any thoughts on a reason this hasn’t been done before?

Thanks for your time, and I really look forward to hearing your thoughts on this!

Jamie Karraker

--

Jeff Lindsay
http://progrium.com

--

Jeff Lindsay
http://progrium.com

[Pedro Melo]

Hi,

I've seen this used internally on at least two companies that I work(ed) for. We currently use this to process integration messages remotely, and on our order flow as a way to enrich a order with extra stuff before reaching the OMS.

When tarpipe.com was around, I tried to convince the developers to use this model, without much luck. I do hope to see parse.com succeed with this, it is an interesting model to pursue.

AWS BeanStalk worker "mode" also uses this: you deploy a web app, and AWS provides a glue component between SQS (their queuing system) and HTTP POST endpoints on your webapp.

Finally, the next items on my agenda for this type of stuff is to replace HTTP with WebSockets as the transport. We would like to see if we can lower the latency of our setup (the endpoints sit around 5000k awy from each other, 150ms on a good day), so all those HTTP handshakes (even with keep-alive we get some) have some impact on this. Why not direct TCP with some light framing on top? Ecosystem… The possibility of using nginx for a lot of our TLS termination, load-balancing and other niceties makes WebSockets very interesting to us…

Bye,

--
You received this message because you are subscribed to the Google Groups "Webhooks" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webhooks+u...@googlegroups.com.
To post to this group, send email to webh...@googlegroups.com.
Visit this group at http://groups.google.com/group/webhooks.
For more options, visit https://groups.google.com/d/optout.

--

Pedro Melo
@pedromelo
http://www.simplicidade.org/
xmpp:me...@simplicidade.org
mailto:me...@simplicidade.org

[Mike Kelly]

Did you consider SPDY instead of WebSockets?

Mike

http://twitter.com/mikekelly85
http://github.com/mikekelly
http://linkedin.com/in/mikekelly123

[Pedro Melo]

Yes, but the server and client libraries to use SPDY are less mature than websockets for now.

I'm sure that going forward SPDY would be a great alternative.

Sent from my iPhone

[ni...@liverowing.net]

Hey Jeff, Could I use webhooks to send user signup emails to MailChimp? I need to keep a clean list in Mailchimp of our parse users. We we are using Mandrill for transactional emails but there is no good integration from Mandrill to Mailchimp for updating lists.

[Jeff Lindsay]

The question isn't what you can use webhooks for, but if your event source provides webhooks.

--

You received this message because you are subscribed to the Google Groups "Webhooks" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webhooks+u...@googlegroups.com.
To post to this group, send email to webh...@googlegroups.com.

Visit this group at https://groups.google.com/group/webhooks.

For more options, visit https://groups.google.com/d/optout.

[Benjamin Young]

Nick,

 

Your best bet is to reach out to Mandrill/MailChimp for support on this one.

 

Cheers!

Benjamin

--

http://bigbluehat.com/

[Nicholas Sheedy]

We used the API for both Mandrill and Mailchimp — we are all set now. Thanks Ben!

You received this message because you are subscribed to a topic in the Google Groups "Webhooks" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/webhooks/4Wck6B8hsLw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to webhooks+u...@googlegroups.com.