They certainly free you from their service by allowing an export of your data. But what about all the code written to the API? If at some point in the future you decide you don't want or can't afford Parse - it's nearly a re-write. Unless you abstract their API in an intelligent way. Even then there is some work.
PostgreSQL 9.3 is installed on your database server, the source is available, and it isn't going anywhere.
If Oracle discontinued their database platform tomorrow (unlikely!), your licensed copy will remain valid for a long time up until you swap it out for another closely compatible database.
If Parse closes their doors or exits tomorrow, that's it.
Compare to AWS: If Amazon discontinues EC2, other virtual hosting services exist. If they discontinue Beanstalk, then at least you were coding to a commmon servlet API. If they discontinue S3, there are some compatible competitors, but hopefully you wrote your data layer to be S3-agnostic.
I think non-standardized AWS services are more risky. More standardized fare -- EC2, Beanstalk, etc -- less risky. Basing your entire code base on pervasive use of Parse -- very risky.
1) There is very little chance of them closing their doors in the near future as they raised a large series A and have great growth.
2) Having personally talked with Tikhon on the subject and it's clear that they plan to make this a stable platform for the longhaul. I would not hesitate to build a project on top of Parse they are a great group and would not leave their users hanging.
3) If you're still hesitant keep in mind you can still keep mission critical stuff on your own Servers/APIs and use Parse for Push Notifications/Location etc.. There is nothing locking you into what parts of the Parse SDK you use.
4) You can always export your data.
Until/unless they get purchased. As you said, it was a large series A.
> 2) Having personally talked with Tikhon on the subject and it's clear that they plan to make this a stable platform for the longhaul. I would not hesitate to build a project on top of Parse they are a great group and would not leave their users hanging.
If they're bought, it won't be their decision.
> 3) If you're still hesitant keep in mind you can still keep mission critical stuff on your own Servers/APIs and use Parse for Push Notifications/Location etc.. There is nothing locking you into what parts of the Parse SDK you use.
Push, etc, is the easy stuff.
> 4) You can always export your data.
It's the continued functioning of the code that I'm worried about, not the data.
With other services you're stuck with their APIs, but at least you can host it on your own server, if the cloud becomes too expensive.
I expect to see an uptick of traffic on exchanges like Flippa as a result of this.
Parse is the first of all these backend-as-a-service startups to face and solve the biggest problem in the web context: user authentication and data security.
By offering a full signup service with email verification and user-level control over the database they have eliminated perhaps the most redundant piece of work that just about every web app has had to implement.
Lock-in is of course a concern, but that hasn't prevent some AWS services from taking off big time. Perhaps in the near future one will see an open source project that offers an off-the-shelf backend with a Parse-compatible API, much like what happened to S3 and etc.
Pricing on the other hand is a concern, particularly if your service requires background workers that constantly update the database -- every update is an API request hit, and one can only wonder what they charge beyond their Pro account.
Overall, I think this is a huge step in the right direction. Because it's the 21st century and one shouldn't have to reinvent the wheel every time one writes a new web app.
I hope so. I agree that user authentication is a redundant piece of any app that needs to be implemented each time. But I don't like the third party lockin.
What if Parse goes out of business next week? Do I have to rewrite all my code that talks to them? I guess I could abstract it enough at the get go to prepare for this.
I think an open source project that isn't tied to a third party would be great.
Huh. I kind of like that. It's a natural anti-monopoly. The service becomes more attractive the more API-compatible competitors it has.
I wonder how they're gaming out that threat. I mean, with an ordinary web host, it's kind of a hassle to switch providers. With something like this, it would take a one-line change and a one-button data-import tool to switch to a cheaper API-compatible provider, right? Talk about a commodity service ...
1) The game takes off and the $200/mo is affordable
2) The game doesn't take off and the 5mil requests is adequate.
The lock-in concerns are valid, but right now their API isn't so mature that it would take eons to build out the pieces I am using in a week or two.
As for the concern with them going out of business, they've raised a good bit of funding, and offer data dumps so you can migrate elsewhere if need be.
For me, right now the ease of development outweighs the risk (we'll see in time though...)
Sorry if that's a dumb question. I'm still trying to wrap my head around what it is.
1) It makes user management stupid-simple. I can authenticate with Facebook/Twitter/signup easily (not that it's really that hard, but still), and the user info is automatically saved to the cloud.
2) I then use it to store game state, retrieve a list of active games/previous games.
3) Push notifications are really easy. Each client opens a "channel", and the other client sends a push to their opponent's channel after their turn is complete.
I suppose I should clarify that I am building a turn-based iPad game, where the game state needs to be stored between turns.
I too am developing a turn-based iOS game using Parse. I've found the entire process to be painless. It's a shame Game Center's turn-based API has so many issues 
Perhaps if iOS 6 is announced at WWDC some of these Game Center issues will be included? For now it's easy enough on Parse to do the equivalent work "by hand".
Perhaps someone could reverse engineer the APIs and provide a Python/Rails + DB back-end.
It scares me to think a user might have the ability to store anything via the web on my dime. I feel like I'm missing something.
You should be able use these in combination to secure your app. If you have more specific questions about how to secure a particular use case, drop us an email at email@example.com and we can help figure something out.
Edit: And I should add that the problem isn't just a user creating new many objects. The problem is that without code controlled exclusively by me somewhere in the middle, business logic (i.e. anything not codified in your database schema) becomes unenforceable. E.g. pull up firebug and type player.levelUp(); player.save();. Now there may be some subset of applications where business logic like this is completely unnecessary, but I can't think of many.
Nothing in their documentation provides any details on this. The security section is filled with details on how to specify access levels, but I can't find anything about how they guarantee Fred is actually Fred and not Bob with firebug open.
It looks like this information is in our "Users" section rather than our "Security" section - we should clean that up in our docs to make it easier to find the right information.
I've wondered about this aspect of Parse for months but not seen a satisfactory answer yet. With the client-side credentials for a Parse app readily available, a malicious user could store any amount and type of data in that app's store, with that app footing the bill.
The easiness of hacking the existing data (say, your SpaceBucks premium currency in a game) is a secondary concern, but it's valid to say that for that extra level of security you need your own servers and logic, and Parse is not the right service.
So I assume we get the token back from the auth call, then we can cookie it for future requests? Once we lose it (cookie expires, cleared, etc.) we just need to authenticate them again. What does the cookie look like? essentially a uuid? How many characters?
It seems like storing the token on the client happens behind the scenes and is checked automatically for calls requiring secured access?
I'd love to see a little more detail in the docs about this.
Assuming auth is handled properly, this is awesome!
We should definitely make the documentation clearer on this point, because this is all stuff that should Just Work.
It's not just games, either. As soon as a client-server solution gets beyond utterly trivial it becomes hard to see how you'd do it without server logic.
Take another example described in lacker's link -- a messageboard post: the ACL defines whether or not a user can make a new post, but what controls the content of that post? What forces HTML tags to be dropped, or limits the number of images in a post, or the size of the post, or checks the domains of links, or prevents xss, or rate-limits a user?
Some of this you can do by treating your entire database as "dirty" and sanitising things on the way out, too, but that doesn't come close to squaring the circle.
You'd probably want to push events into the users profile, have the game ping your server to tell it that there are events waiting, Pull those events on your server and then increment the score. On your server you can have sanity checks and do cheat detection.
1) security. what is preventing an end user from opening a js console and going crazy on the db? How can you ensure consistency when the user has access to the code?
2) Growth. if you choose parse as a platform, the lock in seems like it could cause significant pain down the road.
seems great for toys and demos. I would not run a functioning business on it.
At first, Parse seems like a strategic investment because you don't need IT maintenance on the server, application deployment could be as simple as FTPing static files to a shared host, and all technical aspects of maintaining a database, backups, restores, reboots, DNS and maintenance is attractive to the weekend hacker - or a small scrappy start-up.
The problem is as traction sets in, feature usage and load comes as a total surprise. This is why iteration is fundamental to design.
Overnight a Parse user will need to run backend jobs on the data. Then what? Because the application execution exists within the context of the browser, separate tooling would be necessary. Or what if we needed to access this data from backend infrastructure in real-time?
My point is business demands are demands because the situation calls for it - not because it is planned.
While for most client-centric CRUD type management apps this works great. Its Paas-Rails for scrappy users coming from PHP.
Most web applications worth the web-space they are printed on does something special, or does something simple at great scale.
Access to the data, an IT-based SLA or other guarantees only further positions the business as an IT service provider. My impression of the product was it was targeted for developers and small shops as an application platform with crazy-easy deployment and management. Ultimately the aim is cost reduction in infrastructure IT. I get it.
But any long-lasting business with the momentum built into the plays of most internet companies will outgrow the current version of Parse faster than I believe the growth could be practically followed. That said - proving me wrong would be worth a lot of money.
Anyway - that was the thought process behind that comment. I wasn't trying to be harsh, but if you ask me this oversight is too fatal to ignore.
Of course Heroku and similar services get you most of the way there, but there are plenty of client-side devs who would rather not deal with backend code at all.
These days I can have Ubuntu , Apache , PHP5 , Mysql and Wordpress all working happily on a VPS in under an hour.
On the other hand there are other considerations like maintenance , security and scaling that it might be nice not to have to worry about.
I do that regularly enough. For single server setups, I've got it down to about 60-90 minutes - and that's because I've been too lazy to automate it.
git push heroku master - FTW.
What would be really nice is if Parse had a way to somehow plug in existing backend infrastructure to Parse's data model.
Edit : I take it back. Parse has a REST API.
Annnd you just said that. Didn't see your edit heh.
But for any front-end (or any person, I guess) who wants to build something and quickly validate their idea and get traction this will be very useful.
My only suggestion is to architect your application knowing that you will migrate out of their infrastructure.
I'm wondering if it would be possible to implement a disqus-style service.
Never ever present your product from talking nagative about something or someone else. The only thing this kind of presentation makes me think is "Gee - didn't they have anything good to say about their product?"
2) Facebook and Twitter users
May be that it's not possible to upload files or authenticate using OAuth using only the JS SDK, and without having and external server that secures the private keys?
If I have Users for example and I frequently want retrieve them by their email, I presume you dont do a linear scan every time?