Parse 1.0 is released(blog.parse.com)
blog.parse.com
Parse 1.0 is released
http://blog.parse.com/2012/03/26/parse-1.0-is-released/
10 comments
I wonder how long it will be before someone creates an open source clone of this that you can simply run on any cloud service such as Amazon.
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.
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're not quite "fully launched" at this time, but you might want to check out Trestle:
https://www.trestleapp.com/
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).
https://www.trestleapp.com/
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.
http://blog.parse.com/2012/03/09/one-click-export/
http://blog.parse.com/2012/03/09/one-click-export/
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.
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.
If you find it, please tell us, I asked about it here and got only one reply: http://news.ycombinator.com/item?id=3735387
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:
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.
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.
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:
https://parse.com/docs/android_guide
https://parse.com/docs/android_guide
It looks a lot like they're using https://github.com/jeromegn/DocumentUp Allows you to create sites from markdown files.
At a quick glance the UI looks custom. Looks like they use basic jQuery plugins like "JQuery Waypoints" for the navigation highlighting.
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.
:offtopic:
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.
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 love how their iOS API documentation is laid out in the same style as Apple's documentation!
You have links that point to https://parse.com/pricing which is a generic rails 404.
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).
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.
I'd love to hear more about what other people are using, particularly if tools can find broken JavaScript/AJAX links.
It's not fancy or automated, but I Integrity for Mac every few weeks: http://peacockmedia.co.uk/integrity/
Fixed! Thanks for the note :)
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)
All in all I like the new pricing.
Congrats for the release.
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.
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.
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.
One question I have is what is the advantage of using PFFile instead of storing in S3?
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.
I'm currently using Parse for data and S3 for file storage. I will give it a try to PFFile in another project to see how it works.
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.
Last time I looked at parse I think it used basic http auth over https to authenticate clients.
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?
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?
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.
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?
https://www.parse.com/docs/ios_guide#users-acls
But it's possible to edit the ACL from a client. Isn't that a potential weakness?
https://www.parse.com/docs/ios_guide#users-acls
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?
See this question: http://stackoverflow.com/questions/2135081/does-my-applicati...
See this question: http://stackoverflow.com/questions/2135081/does-my-applicati...
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.
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.
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.
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!
Are you guys taking interns?
One thing that just seems inevitable is that they will be bought, and I wonder if (how?) things will change when they do...