This looks incredible. I've been wanting a clean way to select multiple random objects from my Parse db. Until now, this was the best answer: <a href="https://parse.com/questions/random-search-its-possibile" rel="nofollow">https://parse.com/questions/random-search-its-possibile</a>.<p>Also, it seems possible to combine this with IronWorker. You could create a worker in Ruby, then in the Parse Cloud Code, call that worker's endpoint. Something like this (rough sketch):<p>worker.rb:<p><pre><code> require "some_ruby_email_gem"
cgi_parsed = CGI::parse(payload)
email = payload["email"]
SomeRubyEmailGem.send(email, "Welcome, #{email}!")
</code></pre>
upload.rb:<p><pre><code> require 'iron_worker_ng'
client = IronWorkerNG::Client.new(:token => config['iw']['token'], :project_id => config['iw']['project_id'])
code = IronWorkerNG::Code::Ruby.new
code.merge_worker 'worker.rb'
code.merge_gem "some_ruby_email_gem"
client.codes.create(code)
url = "https://worker-aws-us-east-1.iron.io/2/projects/#{config['iw']['project_id']}/tasks/webhook?code_name=#{code.name}&oauth=#{config['iw']['token']}"
puts "Add this url to to your Parse Cloud Code:"
puts url
</code></pre>
Parse Cloud Code:<p><pre><code> Parse.Cloud.define("welcome, function(request, response) {
var user = request.object.get("user");
var url = "https://worker-aws-us-east-1.iron.io/2..." // the url from upload.rb
http.open("POST", url+"?email="+user.email, true);
});
</code></pre>
EDIT: HTTP requests to 3rd parties within Cloud Code are not possible <i>yet</i>, but Parse will add the feature soon. (<a href="http://twitter.com/ParseIt/status/245584646686003200" rel="nofollow">http://twitter.com/ParseIt/status/245584646686003200</a>)
This looks great and should solve a number of issues with the current API.<p>I have an app that basically tracks donations for different campaigns. Getting total donations per campaign isn't easy with the current API. There is nothing like a "select sum()" statement in Parse. Basically I currently have to run a cron job on my machine that will periodically download all donations by campaign and update the total donations field on the campaign (the regular user account doesn't have privileges to edit the campaign object).<p>This seems like it will be a much cleaner, saner way to take care of this type of task.
It seems like Parse will be in a never-ending battle to continue adding functionality on the back-end to approach what one gets when they simply run their own back-end. Surely there is a happier medium?
Finally! I can run server code! I just might take another look at them now!<p>Edit: Huh? Why was this downvoted? The problem I've had with Parse for a long time was that I still needed a separate server to do some backend processing that was not feasible to do on a client. Now I may no longer have need for that server.
It seems to make sense. Looks similar to the way Windows Azure Mobile Services lets you run JavaScript code on the server.<p><a href="http://weblogs.asp.net/scottgu/archive/2012/08/28/announcing-windows-azure-mobile-services.aspx" rel="nofollow">http://weblogs.asp.net/scottgu/archive/2012/08/28/announcing...</a>
This is great! And perfect timing! Just today I was starting to write a set of external hosted scripts to generate XML from my Parse objects, but this makes everything much easier. Parse is just terrific!
This definitely lifts off the cons I've had so far with Parse, adding logic to the backend instead of just a pure data storage. Awesome job to the Parse team
This is great news.<p>I've been using parse on a project and was missing this functionality.<p>As a side note, I'm loving parse, but their iOS SDK is poorly designed. Like really badly designed. I had a few email exchanges with one of their devs, but it didn't really seem to go anywhere. You can't create subclasses of any of their objects because they like using static methods versus singleton instances. It's really stupid and it really ties you to using parse. You also have shit like this everywhere:<p><pre><code> NSString *someval=[pfobject objectForKey:@"shit"];
</code></pre>
Where this would be preferred:<p><pre><code> NSString *someval=mySubclass.shit;
</code></pre>
So you can create a wrapper/shim for PFObject, but that doesn't float across queries returning arrays of objects.<p>And, yes, I considered writing my own wrapper around their REST API but I don't have that kind of time.
This is great, but not quite what I had hope for. Yes you can run custom code, but only what their current API allows. It just saves time by not having to transfer data to the client to aggregate.<p>Step in the right direction though.
how is this priced?<p>a cloud code request probably can't fit within the pricing model posted on the parse site as a single API request because it may presumably have huge variance in resource consumption. like what's to stop someone from use parse's resources to run bitcoin miners?
What now is an API call that counts towards your quota? An API call to the Cloud Code from the client, or each call to a Parse method within the Cloud SDK?
How is it everyone's opinion of PaaS went sour when Google AppEngine readjusted its pricing to reflect costs. Now someone else comes along and PaaS is the greatest thing since sliced bread.<p>These guys will never be bought by a bigger company with nothing but profits in mind?