HN Explorer

20 comments

[ 4.2 ms ] story [ 47.0 ms ] thread
julianpye
Lovely! Such simple integration with Twilio is simply excellent in combination with the push features. Keep those partnerships coming!
davidu
This makes a lot of sense. Not at all surprised to see Parse continuing to kill it.
pagliara
Nice work! Perfect timing too as I was just trying to figure out the best way to integrate Twilio into an iOS app already using Parse.
xoail
I gotta say Parse has a great CEO. The key to success is partnerships in the direction of innovation and expansion of offerings based on consumer needs. Creating win-win deals not only between you & your customer but also between you & your partners. I wrote an email to Parse few weeks ago on possible integration with Twilio. Never heard from them, and now see this. Good stuff.
nacs
If this thing uses Javascript on the client side to send email or make phone calls, couldn't any visitor modify the Javascript to email anyone with any message (or make phone calls to anyone)?
mattieuga
Cloud Modules use JavaScript but not on the client. They are used in Cloud Code (www.parse.com/docs/cloud_code_guide). You basically write JavaScript hooks and functions that run on the Parse servers.
rudasn
I am really impressed with the direction Parse is taking. It seems to me they are fixing the right problems and they are doing it step by step.

One thing I would love to see, is a way (an API) to abstract their Javascript library. I would really like to use another JS library other than their own. That would make the cloud code feature even better for me.

I am wondering how long it will take them to stop marketing themselves as a mobile app platform. They are [becoming] much more than that.

napoleond
I haven't had a chance to use Parse yet, so I'm curious: what's wrong with their JS library, and couldn't you use the REST API directly instead?
mikebridgman
One thing I noticed is that their library is essentially Backbone and Underscore, and their docs state that it has all existing functionality...except I keep finding functions that aren't included, so I still have to load my own version of Backbone.

But you're right: for my next app, I'll probably just use their REST API directly.

napoleond
Odd. I wonder why they didn't just override Backbone.sync.
lacker
There is some stuff that we want to handle differently, like when you increment a field it is usable locally but maps to an increment operation rather than a set on the server. So for a slew of details like this, overriding Backbone.sync wasn't quite sufficient. I hear the concerns about the trickiness of using plain Backbone with Parse, though - that is a design issue we are thinking hard about.
seansmith23
I love that Parse reads StackMob's blog: http://blog.stackmob.com/2012/08/rocking-twilio-sms-with-sta...
shykes
Wow, that is a very similar announcement from a very similar product.

Superficially it seems that Parse and Stackmob are executing on the same vision, at roughly the same velocity. Yet Parse seems to get more publicity these days. Is it just that they'r e better at engineering hype and projecting the image of success, or is it something else?

yefim323
They're also releasing a module for underscore which is pretty exciting!
fieldforceapp
Gotta say, these guys are really killing it... and love the quick turn-around @csmajorfive on my comments last month, now just get going on the local caching :-) http://news.ycombinator.com/item?id=4700062

I'd say Parse is aiming to take on SF.com / Heroku with this, it's certainly causing me to rethink a custom Rails3 stack we have in the works...

bengl3rt
I just read the entire Cloud Code and Cloud Modules documentation, and there's one thing that doesn't quite make sense to me. There seems to be a piece missing.

So you implement some HTTP API using Cloud Code, and you deploy it. Shouldn't their SDK, through magical synergy, expose the native function to communicate with that API on the device? It seems like I can implement my HTTP API using Cloud Code, but I still have to bring in something like RestKit or ASIHTTPRequest on the device to actually talk to it.

So they have native APIs for talking to their HTTP API, but not the custom ones you implement using cloud code? Their example shows them calling it with curl, rather than "here's how to call this from inside your native app that already uses all the other Parse goodies"

lacker
The API is exposed natively. Where you see the curl examples, there is a dropdown to show how to do it in other languages.

  [PFCloud callFunctionInBackground:@"averageStars"
           withParameters:@{@"movie": @"The Matrix"}
           block:^(NSNumber *ratings, NSError *error) {
    if (!error) {
       // ratings is 4.5
    }
  }];
We should probably default to something other than curl or tweak that UI a bit. Thanks for pointing this out.
bengl3rt
Cool! That's what I was looking for.

Yes, it's a bit buried. I missed the dropdown on the right. Speaking of Twilio, their docs are very good for stuff like this. They use a big obvious segmented control for switching between XML and JSON, for example.