Parse is my most favorite company I've never used (but I'm actively searching for an excuse to become a user).
Just watching them build out their impressive platform in mere months has been enough to make me a fan.
One thing that just seems inevitable is that they will be bought, and I wonder if (how?) things will change when they do...
If you forget about the iOS SDK for a minute, Parse is essentially a modern CouchDB.
Couch got a lot of things right, and with the advent of client-side apps I'm guessing the idea of database-as-API makes a ton more sense to people now than it did five years ago.
But because CouchDB wasn't made with modern web app development in mind, it has these awkward almost-right-but-not-quite features, like the way it handles push notifications (see http://guide.couchdb.org/draft/notifications.html), design documents, couch apps, map/reduce and so on. All of that stuff is great, but none of it works quite as smoothly as it should.
Anyway, I would love a database with these features:
* RESTful, with basic filtering operations built-in
* schemaless
* uses webhooks to provide push notifications, plugins (e.g. ACL, validation) and map-reduce -- meaning you can "program" your database using any language you want, couple events to background jobs etc.
* websocket support
* multiple engines so you can back a collection with Mongo, Redis, Neo4j, S3 (store/serve media) or anything else depending on your requirements, but still have all collections exposed to the web as JSON with a uniform querying interface
* smart view caching
The trouble with Couch is that you're supposed to be able to build apps that are backed with just your database and nothing else, but it never ends up being quite flexible enough to do exactly that.
But a database that would allow you to replace your entire back-end framework with just a couple of independent snippets of code to handle validation, authorization, sending email and what-not but with all the CRUD you need for an API-driven app out of the box... hells yeah.
While I like the simplicity that Parse promises, I do worry a little about having my users' data being potentially held hostage by a 3rd party..
what if I publish a wildly successful app and store all my users's data using Parse, and then one day they decide to triple their prices? Or maybe sell their business to Google who decides to shut down the service?
As stdbrouw mentions it's basically a CouchDB, I thought about using it in my own server.
However I prefer to use Parse to handle all that without me actually caring about the server side issues and specially given that the price is quite cheap for what my apps need.
Another advantage is their SDK that simplifies communication with the backend even further.
One thing that I don't like is that they don't have a way to add Server Side logic (as Cloudmine does) so my current solution is having a separate heroku instance for those cases.
I had a close look at the iOS SDK of Parse - I read the API documentation as well as the guide. To me it seems that they got it right. The SDK can do so much for you and yet the API seems to be very simple and streamlined. Very very pragmatic and I like it. Look at the SDK Reference:
I see about 10 classes there. Isn't that awesome? 10 simple classes - thats it. To make it more concrete - have a look at PFObject. This simple class seems to be a wrapper around NSDictionary but it gives you CRUD commands and it is using setObjectForKey: and objectForKey:. If I show this class to one of my Objective-C students they will immediately know how to use it.
Parse really knows how to make complex things easy going. I will evaluate Parse with a real app soon but I am very confident that it will be a good experience.
Anyone know what they're using on their website for documentation? I love the way the pane on the is highlighted as you scroll the main window of this page:
I remember a frontpage 97 feature that scanned your site for broken pages. Seems like we need a web 2.0 version of that (because I've noticed a new/small sites with dead links recently that should have been [automatically] caught).
There does seem to be an opportunity here. The free tools I've used for doing this all hit the web server and are either command-line based (wget, etc.) and/or ancient: "Xenu's Link Sleuth" for Windows. ( http://home.snafu.de/tilman/xenulink.html )
I'd love to hear more about what other people are using, particularly if tools can find broken JavaScript/AJAX links.
Looking at the new pricing, by storage size vs number of objects looks like a good change. You and parse benefit by making smaller objects.
Kind of sorry to see the $49/month plan go. The jump from free to $199 seems a little steep. (I know there is pay as you go for the basic level, but I'd kind of like to know the costs before hand)
I've been curious how they handle indexing given that they allow ad-hoc queries. In the feature list they say that they provide "smart indexing". I wonder if they simply log all queries and generate sparse-indexes (they use MongoDB) on the fly? I wonder if "file storage" counts index space?
Parse is great, I had some trouble with their iOS Facebook documentation and they were all too happy to email me the changes that recently occurred and update their documentation accordingly.
I use Parse on a couple of projects, I also work (separately, I hasten to add!) on apps for carriers with significant security issues.
I would say that you shouldn't really worry about 'sniffing' traffic, because whatever countermeasures you take chances are if someone cares enough they'll work around it.
Parse has an access-control model for objects: objects can have read/write permissions for users, groups, or everyone. For example, you might have an object in Parse representing a comment, which the owner could edit and everyone else read.
Obviously the Parse API itself is rather public, and it wouldn't take a huge amount of skill to extract your client keys from an Android / iOS app: but as long as you've designed your ACL (access control list) correctly, it won't matter as your user will have to be logged in and authenticated to access sensitive objects.
There is per-user authentication. The PFUser class (in iOS, Android is ParseUser) handles this sort of authentication automatically for you, and there are also hooks to do it with a bit more effort through the REST API.
I see you guys are in geolocation. I have some interesting client-side code for identification and cleaning of Postal addresses in HTML (runs in the browser or backed). If you might be interested in discussing, drop me a mail!
[+] [-] clemesha|14 years ago|reply
One thing that just seems inevitable is that they will be bought, and I wonder if (how?) things will change when they do...
[+] [-] joelthelion|14 years ago|reply
[+] [-] stdbrouw|14 years ago|reply
Couch got a lot of things right, and with the advent of client-side apps I'm guessing the idea of database-as-API makes a ton more sense to people now than it did five years ago.
But because CouchDB wasn't made with modern web app development in mind, it has these awkward almost-right-but-not-quite features, like the way it handles push notifications (see http://guide.couchdb.org/draft/notifications.html), design documents, couch apps, map/reduce and so on. All of that stuff is great, but none of it works quite as smoothly as it should.
Anyway, I would love a database with these features:
* RESTful, with basic filtering operations built-in
* schemaless
* uses webhooks to provide push notifications, plugins (e.g. ACL, validation) and map-reduce -- meaning you can "program" your database using any language you want, couple events to background jobs etc.
* websocket support
* multiple engines so you can back a collection with Mongo, Redis, Neo4j, S3 (store/serve media) or anything else depending on your requirements, but still have all collections exposed to the web as JSON with a uniform querying interface
* smart view caching
The trouble with Couch is that you're supposed to be able to build apps that are backed with just your database and nothing else, but it never ends up being quite flexible enough to do exactly that.
But a database that would allow you to replace your entire back-end framework with just a couple of independent snippets of code to handle validation, authorization, sending email and what-not but with all the CRUD you need for an API-driven app out of the box... hells yeah.
[+] [-] nanijoe|14 years ago|reply
[+] [-] jagbolanos|14 years ago|reply
However I prefer to use Parse to handle all that without me actually caring about the server side issues and specially given that the price is quite cheap for what my apps need.
Another advantage is their SDK that simplifies communication with the backend even further.
One thing that I don't like is that they don't have a way to add Server Side logic (as Cloudmine does) so my current solution is having a separate heroku instance for those cases.
[+] [-] Ecio78|14 years ago|reply
[+] [-] LinaLauneBaer|14 years ago|reply
https://parse.com/docs/ios/api/
I see about 10 classes there. Isn't that awesome? 10 simple classes - thats it. To make it more concrete - have a look at PFObject. This simple class seems to be a wrapper around NSDictionary but it gives you CRUD commands and it is using setObjectForKey: and objectForKey:. If I show this class to one of my Objective-C students they will immediately know how to use it.
Parse really knows how to make complex things easy going. I will evaluate Parse with a real app soon but I am very confident that it will be a good experience.
[+] [-] dkl|14 years ago|reply
https://parse.com/docs/android_guide
[+] [-] loganbailey|14 years ago|reply
[+] [-] seanmccann|14 years ago|reply
[+] [-] Derbasti|14 years ago|reply
[+] [-] latch|14 years ago|reply
I remember a frontpage 97 feature that scanned your site for broken pages. Seems like we need a web 2.0 version of that (because I've noticed a new/small sites with dead links recently that should have been [automatically] caught).
[+] [-] j_s|14 years ago|reply
I'd love to hear more about what other people are using, particularly if tools can find broken JavaScript/AJAX links.
[+] [-] jamesjyu|14 years ago|reply
[+] [-] ambirex|14 years ago|reply
Kind of sorry to see the $49/month plan go. The jump from free to $199 seems a little steep. (I know there is pay as you go for the basic level, but I'd kind of like to know the costs before hand)
All in all I like the new pricing.
Congrats for the release.
[+] [-] latch|14 years ago|reply
[+] [-] xelfer|14 years ago|reply
[+] [-] fberger|14 years ago|reply
Having seen how easy it is to look at the plain traffic a mobile app sends with http://mitmproxy.org/ I would have concerns to use this.
Or is there some per user authentication?
[+] [-] objclxt|14 years ago|reply
I would say that you shouldn't really worry about 'sniffing' traffic, because whatever countermeasures you take chances are if someone cares enough they'll work around it.
Parse has an access-control model for objects: objects can have read/write permissions for users, groups, or everyone. For example, you might have an object in Parse representing a comment, which the owner could edit and everyone else read.
Obviously the Parse API itself is rather public, and it wouldn't take a huge amount of skill to extract your client keys from an Android / iOS app: but as long as you've designed your ACL (access control list) correctly, it won't matter as your user will have to be logged in and authenticated to access sensitive objects.
[+] [-] lacker|14 years ago|reply
https://parse.com/docs/ios/api/Classes/PFUser.html
If you have more specific questions about how to use this for an app, feel free to drop us a line at feedback at parse.com.
[+] [-] peteretep|14 years ago|reply
[+] [-] HackR|14 years ago|reply