

Show HN: Simple app-to-app messaging with a hosted server and common interface - dropfrog
http://dropfrog.io

======
tylermauthe
This is a really cool service, but I have some questions after reading through
everything:

\- You say it is HTTPS over a persistent TCP connection, does this mean I can
make standard HTTP request... Like using xhr from JavaScript?

\- Any plans for SDKs or libraries? Example code in popular languages
perhaps...

\- How is this different from Parse? (Except less developed)

Also, some feedback:

\- Make it easier to understand the main benefits quickly, I had to read the
small text

\- I love the simplicity of the product, keep it simple \- The pricing is
weird... Not sure what to recommend, but $1.50 just seems weird. Too low?

edit: formatting

~~~
dropfrog
Thanks for the feedback. This is a great community. I would love to have more
examples on the site. I have included a fully functional Java client on the
code page, and will be looking at Objective-C/Swift as well as your suggestion
for JavaScript. Asynchronous-response-capable and HTTPS is the basic
requirement...if the XHR works I will post the examples on the site.

Regarding comparisons, the DropFrog emphasis is ephemeral messaging--the API
is all about communication/messaging between the connected clients and when
there are no more channel participants, the channel is destroyed. I have also
toyed with the idea of adding limited persistent storage capability; will be
listening to feedback.

The pricing is rock bottom, but designed to be sustainable with the current
feature set.

~~~
tylermauthe
Ephemeral messaging sounds cool, you should plug that somewhere on your site.
Standing out will be good for business.

My initial concern is connection stability issues. What happens if the
client's connection drops out for a period of time? Do clients have to
explicitly leave the channel?

My team was estimating a story recently which could have used this, but we
didn't want to spend the time and effort to build a whole infrastructure for
one message. This would have been perfect! If I find some time, I'll give it a
try and send you my feedback.

~~~
dropfrog
A client TCP connection close, whether intentional or due to network failure,
does quickly remove the participant from the channel.

~~~
tylermauthe
Got it... I'm not sure I understand the use case for this tool then?

In a browser, the TCP connection will close itself. On a mobile device, the
TCP connection will close when the network connection drops.

I suppose a server could reliably keep a TCP connection open, but at that
point why wouldn't I just deal with the messages myself..?

~~~
dropfrog
Mobile device connections work well enough -- a reliable VOIP app on Android
was constructed with the DropFrog service on the backend. Generally, a network
connection can get dropped on any device even for a "server" device; it is a
failure case to anticipate and program accordingly. On DropFrog, by the way,
the channel continues to exist if there are any participants and also for half
a minute with no participants whatsoever, anticipating and accommodating
failure cases. For the browser (and more) consideration, WebSockets under
control of the application programmer makes the most sense, fulfilling the
requirements of a persistent and secure connection (WSS). WebSocket support
will be added in the future.

~~~
tylermauthe
Awesome! Thanks for the info. Good luck with the product, hope to find some
time soon to try it out.

------
ksikka
I'd love to see some real-world examples on the front-page. I think I get the
concept but not sure how I'd actually use it in a chat app.

Cool service - I like the approach.

~~~
dropfrog
Good stuff - the generic broadcast example has now been replaced with a
working chat example and there is a link to it from the front page.

