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):
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
Parse Cloud 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);
});
This looks great and should solve a number of issues with the current API.
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).
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?
Our goal is to help you build great mobile apps faster. We want Parse to be not just easier than running your own backend, but also more powerful. If that involves a lot of hard work on our part, so be it.
I think Cloud Code is a good example of why this is not the case. The more flexibility and customization they allow in the platform, the fewer long tail features they need to implement because people will be able to do it themselves.
I imagine the argument is "once you add Cloud Code and people start using it to solve problems, you have pretty much re-built Google App Engine"; it means the only thing that separates Parse/StackMob/CloudMine (which now all have this feature) is that they come with a simple default app which provides an HTTP API to the data store that is used by an even simpler client library.
Right, because they provide the two things I stated: a default app on the other side that provides fairly liberal access to your schema, and a library that can be used on the client that provides a fairly reasonable API (maybe even CoreData integration; I know some of their competitors do this) to access that API.
Neither of these, however, are that complex to do, and the value of both of these drops dramatically once you start writing server-side logic in Java.
Finally! I can run server code! I just might take another look at them now!
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.
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
I've been using parse on a project and was missing this functionality.
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:
Helping subclassing to work more smoothly is definitely on our minds. A lot of people do subclass PFObject right now, and as you point out that means you need to handle queries in a slightly different way. It could be nicer, though, and we intend to make it nicer.
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.
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?
The environment is based on V8, which provides a lot of tools to sandbox javascript code. There's some other pretty cool technology there - we might write a more detailed blog post about it if folks are interested.
In late 2009, I had an idea to create a service that would allow game developers to run JavaScript on the server to drive multiplayer games.
I worked on it for about 6 months and then Apple released Game Center. It was pretty clear that my service would be eclipsed by Game Center so I threw in the towel on it.
At the time, I was targeting Node.js on the server and wrote a fledgling sand-boxing tool called Jefe [1].
I'm using Parse in my current app (Lexatron [2]) and I'm loving it. I'm looking forward to see what I can run on the server side.
Cool. I assume you guys are using an Isolate with multiple contexts/threads to deal with infinite loops and sandboxing restrictions without the overhead of additional processes? We (clay.io) are working on a very similar problem in the game space.
Another question (just curious): why did you cut node out entirely? libev is awesome and it seems like you would basically have to rewrite if you used straight C++.
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?
They use MongoDB, and MySQL. This worries me immensely. The Mongo part more than MySQL, only because historically, MongoDB has not had a great story around HA, and reliability...
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.
These guys will never be bought by a bigger company with nothing but profits in mind?
No: this is more about being able to define middleware that allows you to process information that would either be too costly to transfer to one of the clients or which is too sensitive to be trusted to a client.
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):
worker.rb:
upload.rb: Parse Cloud Code: EDIT: HTTP requests to 3rd parties within Cloud Code are not possible yet, but Parse will add the feature soon. (http://twitter.com/ParseIt/status/245584646686003200)