Allow for Replay in Service Browser

[cfjedimaster]

One cool thing that ngrok does is let you "Replay" a request. This is useful for when you are testing a remote service and don't want to keep asking it to ping you.

[coreybutler]

I assume you're thinking of replaying a webhook, or were you thinking of a web request? I suppose it would be possible to do both.

ngrok is pretty awesome, and it does have some features localtunnel doesn't have. My original hesitation was the fact it's written in Ruby and I tried to keep the dependency tree small.... but I have enough personal curiosity to play around with using ngrok instead of localtunnel the next time I get a chance to hack on this part.

[cfjedimaster]

Web hook, web request, whatever. :)

Although now that I think about it... it may not make sense. You see, I was
imagining me writing server side code to process web hooks. I'd rather do a
replay as opposed to "really" firing the web hook so I can test my code.

But in this case, your Service Browser is just reporting on the pings. It's
not like i can chain that to Node.js or ColdFusion or something.

Right?

On Fri, Jun 27, 2014 at 8:12 AM, Corey Butler notifications@github.com
wrote:

I assume you're thinking of replaying a webhook, or were you thinking of a
web request? I suppose it would be possible to do both.

ngrok is pretty awesome, and it does have some features localtunnel
doesn't have. My original hesitation was the fact it's written in Ruby and
I tried to keep the dependency tree small.... but I have enough personal
curiosity to play around with using ngrok instead of localtunnel the next
time I get a chance to hack on this part.

—
Reply to this email directly or view it on GitHub
#42 (comment).

Raymond Camden, Web Developer for Adobe

Email : raymondcamden@gmail.com
Blog : www.raymondcamden.com
Twitter: raymondcamden

[coreybutler]

I don't think the use case you had in mind makes immediate sense for Fenix since it's designed to be the receiver, not the originator of a webhook. However; it challenged me to think about this in a different way.

I'm also doing webhook work in both Node and CF, and I can see the value of a replay when processing a webhook. It would be possible to proxy traffic through Fenix to the endpoint, therefore allowing it to capture request/response attributes. With that data, replays would be possible. I think RequestBin does something like this. I'll have to think about the overall workflow involved, but I think there might be something to this.

As it happens to be, I'm actually working on a webhook debugger for a commercial service. I've already got a few non-proprietary nuggets along these lines that could find there way into Fenix... might not be until the next version though.

[cfjedimaster]

Yeah - if Fenix could proxy the call to something like
http://localhost/mycfc then a replay would make sense. So then Fenix
becomes my easy way to let an external service hit my stuff as opposed to
just being able to view the requests.

On Fri, Jun 27, 2014 at 12:26 PM, Corey Butler notifications@github.com
wrote:

I don't think the use case you had in mind makes immediate sense for Fenix
since it's designed to be the receiver, not the originator of a webhook.
However; it challenged me to think about this in a different way.

I'm also doing webhook work in both Node and CF, and I can see the value
of a replay when processing a webhook. It would be possible to proxy
traffic through Fenix to the endpoint, therefore allowing it to capture
request/response attributes. With that data, replays would be possible. I
think RequestBin does something like this. I'll have to think about the
overall workflow involved, but I think there might be something to this.

As it happens to be, I'm actually working on a webhook debugger for a
commercial service. I've already got a few non-proprietary nuggets along
these lines that could find there way into Fenix... might not be until the
next version though.

—
Reply to this email directly or view it on GitHub
#42 (comment).

Raymond Camden, Web Developer for Adobe

Email : raymondcamden@gmail.com
Blog : www.raymondcamden.com
Twitter: raymondcamden

[coreybutler]

Yeah, I really like the idea of providing that tunnel BOTH ways. I've got some thinking about the best way to approach it, but consider this on my priority list - and not just because it would save me a TON of time :)