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.
We don't meet all your bullet points from above, but your closing paragraph sums up what we're doing with Trestle pretty well (i.e. more than just a web connected database).
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?
We don't want to hold your data hostage. We're convinced the right strategy is to make it easy to migrate off Parse, so that people won't be concerned when moving onto Parse. For example, we recently launched one-click export, so you can get out all the data your app is storing on Parse without writing any code.
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:
Yep, the documentation UI is custom, on top of typical jQuery stuff. We looked at off-the-shelf solutions, but none of them were quite awesome enough, and it's really important to us to have great documentation, so we ended up rolling our own.
Could you turn off the CSS for changing the highlight color? I know it is all the rage these days, but it is an accessibility issue for me (and probably others as well). I use highlighting to make it easier for me to read text (it helps by eyes track better). When you change the color (especially to something garish) it substantially reduces the usability of the site for me. Yes it is just one Firebug edit away, but really I shouldn't have to do it.
Operating systems allow people to set custom highlight colors for a reason. I don't see why website authors think they know better than their users.
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?
"File storage" actually only counts large files that are stored with PFFile / ParseFile. It does not include data stored in objects or index space; those are all covered by pricing for API requests.
We do track queries and accesses to create appropriate indexes on the fly. Whenever we used databases in the past, indexes always seemed like something that should be done intelligently out of the box, so we decided to make Parse work that way.
Ok, that makes sense. At the beta pricing I was looking at the free tier and thinking it would be limiting some one to 50k users (IIRC PFUser is a subclass of the PFObject). So now we are limited by API calls, I suppose that would mean inactive users don't really count towards usage, which was a problem I was thinking about.
We think PFFile is a lot easier to use from mobile devices, with the iOS and Android SDKs. A lot of people are actually just using PFFile because they find it simpler than using S3. That said, you can use S3 and Parse in the same application, so they work together fine if you'd rather implement things that way.
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.
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.
But it's possible to edit the ACL from a client. Isn't that a potential weakness?
Editing the ACL is subject to the same access restrictions, similar to how Unix ACLs work. So, for most cases this is sufficient. If you have more complex security needs, we're glad to discuss how individual apps can be secured. Drop us a line at feedback at parse.com.
Thanks. And I will likely do that. Before I do and if I could borrow some more of your time: would using Parse qualify an app as containing encryption, in regards to the AppStore submission/guidelines?
Parse does use https:// connections for all data, so you should take whatever action you would normally take for an application that communicates over https. That is the only form of client-side encryption used.
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!
One thing that just seems inevitable is that they will be bought, and I wonder if (how?) things will change when they do...