These guys are really onto something. Playing with their stuff for a little while was at once fun and annoying: I'd have killed to have this tech when I was an indie iOS dev, trying to scrape by knowing nothing about server development.
Seriously, I'd come up with cool features all the time, but have no idea how to get started building the server components they needed. Parse abstracts all that pain behind a few Objective-C methods that work just like all the other frameworks I use each day. I can store arbitrary data to the cloud and construct specific queries to pull it back down – without the mental overhead of learning or maintaining a new stack.
It's a simple idea but it's implemented with enough clarity and flexibility that you can accomplish a lot of neat stuff. Huge cheerleader for this team – I think they've got a lot to offer the many mobile developers who have ambitious projects and limited time/budget for outside server help.
Basecamp gives you the comfort of not having to think about running your own project management software.
GitHub gives you the comfort of not having to think about hosting your own git repositories.
Doesn't every Software as a Service and Platform as a Service company strive to "give you the comfort of not having to think about" running some piece of software on your own servers? The incessant comparisons to Heroku are just silly now.
I'm an IOS developer, and to be honest I wouldn't use Parse (at least not today).
1) Unless you're building a mobile client for an existing website, would you really bother with authentication? Can't you just transparently store users with a UDID?
2) Client-side caching is the biggest pain in IOS apps. Network calls are relatively easy. I try to make simple/dumb calls to the backend and just do smart filtering and data manipulation on the front end. Parse doesn't really help here. Do they have integration with core data? They don't even seem to mention it.
3) Some of those testimonials are hilarious, but clearly fake. Why not use real ones?
4) You usually need a server running for a landing page, anyway.
5) No support for storing images or audio. Storing simple strings isn't that useful.
This is really useful feedback, especially #2 and #5. Better support for caching and other filetypes are features we're working on for upcoming releases. If you don't mind, I'd love to get your feedback in more detail - if you could shoot me an email at kevin@parse.com that would be great. If you're in SF I'll buy you lunch sometime ;-)
Using UDIDs for authentication isn't a good idea for a serious app. Even if it were unspoofable, devices aren't users. Users have iPhones and iPod Touches and iPads; they upgrade; they sell devices to other users.
Let me rephrase - if I were making a game, I wouldn't bother with a username and password. What's the point? Just ask for a nickname when entering the high scores :)
Pricing? Free during beta is nice, but if this is $99/month after, that will weed out weekend projects. Also, is it a per-app cost, per-user, per-company, or something else? Per-user weeds out free apps. I like the concept, but it doesn't make sense to use it without knowing what rough order of magnitude cost I'm looking at when it goes live.
We definitely don't want to weed out weekend projects or free apps. The goal is to have a pricing model similar to Heroku's, where you pay more than you would for a Linode box, but not a ridiculous amount more.
This. There's always a backlash with unexpected post-beta price increases as well (see google app engine.) Be straight-up with the pricing and hold your words.
I don't see how anyone can even build on a proprietary platform without knowing the costs upfront. Google was different in that google allowed you to use existing frameworks such as spring and jpa, and if you encapsulated the code properly , migrating was easy.
I completely agree. I've got a linode instance and use it for server side stuff, but I hate doing server side stuff. This seems awesome, but I'm going to hold off until I know I can afford it.
What I really want (and would pay money for) is something like PhoneGap but which lets me code in HTML5 and then deploy into the Android Market and iPhone AppStore at the push of a button, Without having to use Java/Objective C.
Why has no one provided this product yet? Do the TOS for Android Market and AppStore make this impossible?
(To be clear: The deployment part is the part I want, the part that I don't want to have to fuss with)
I've been following the development of Parse for the past couple months. Really solid progress. What struck me as the coolest part of their product is the ActiveRecord/ARel-style querying:
>ParseQuery query = new ParseQuery("GameScore");
query.whereEqualTo("foo", "bar").whereEqualTo("baz", "biz");
The ability to stack query options like that is very Railsy. I have a feeling that as more Rails developers focus on mobile development, they will take some of the nicer API designs with them into the Java/Obj-C world.
The guys behind this are incredibly smart. I really wish them the best of luck.
I do agree with @biot though. Pricing needs to be better defined and there needs to be the ability for people with side projects to be able to integrate this without forking over $99 a month.
I feel that the much bigger users would be building their own service instead of using Parse as it would be more economical anyway.
It's a useful analogy. Heroku abstracts server configuration away from Rails development to the point where it's (theoretically) completely unnecessary to know /anything/ about it. If this does the same thing in a different context, I think it's a fair comparison.
Looks fantastic. I'm personally really interested, and would like to know:
* Pricing - beta/free won't last forever!
* How will this compare with using iCloud when it comes out? I believe that icloud will provide api's for some storage/syncing capabilities.
iCloud's data functionality so far is very user-centric and doesn't let you store app level data. It certainly will never seamlessly work with Android and other platforms.
Parse, Kinvey and StackMob are great tools if you want to read/write data such as high scores from your app. But you won't have a nice editing interface for the data in the web.
If Parse is "Heroku for Mobile" then StorageRoom, the startup I am working for, is "iCloud for content".
Editors manage content in our flexible service online and data is synchronized or pulled from mobile apps.
Different use-case, but we seem to have found another problem where many devs complain. Existing CMS tools suck at this.
Their API's pretty easy to work out since you can NSLog the Objective C stuff to see what and how it's sending. I did it last week to make Parse available to my ActionScript, HTML5 and Unity developers.
I realize that names of companies or services don't have to be descriptive but surely it's a good idea for them not to describe perfectly something completely different...
It's not completely different. In a literal sense, if you use Parse, you don't have to parse JSON or XML in your mobile app. And in a general sense, we think of "parsing" as taking a big messy problem and making it simple.
Will Parse provide offline support? I saw sync mentioned, but it seemed to be more with respect to syncing multiple devices by virtue of a common web-based datastore.
We try to provide an API that's flexible enough to do a lot of different things. You can also use Parse for some of your features, and roll your own for others.
If you have a particular use case in mind, we'd love to hear more about it at feedback@parse.com.
I had a similar reaction when I first heard about it, but quickly realized it's definitely capable of offering a lot more than that.
Parse is like an envelope labeled "Instant Server Guy – Just Add Water." If you need your app to be able to create/query/display remote data between users, damn, you've got a huge head-start just by dropping in their code.
Seriously, I'd come up with cool features all the time, but have no idea how to get started building the server components they needed. Parse abstracts all that pain behind a few Objective-C methods that work just like all the other frameworks I use each day. I can store arbitrary data to the cloud and construct specific queries to pull it back down – without the mental overhead of learning or maintaining a new stack.
It's a simple idea but it's implemented with enough clarity and flexibility that you can accomplish a lot of neat stuff. Huge cheerleader for this team – I think they've got a lot to offer the many mobile developers who have ambitious projects and limited time/budget for outside server help.