I'm of two minds about this. On one side I think it's a very smart service to use. It removes what otherwise might be a ton of work to duplicate. On the other side I think it's a very dumb thing to be bound to.
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.
They do promise that it's easy to port your backbone.js app to Parse Javascript SDK, which implies it may be relatively easy to port back. Backbone and Underscore are open source frameworks, so they're not a bad starting point for those considering this.
This argument applies to all APIs however. And I can't see any reason why Parse wouldn't be "vulnerable" to another service/library with an identical API (in the non-web world, this has happened often).
This might be a big boost for the website resale business though. Today if I want to buy or sell a website I have to handle a messy handoff of server infrastructure but if it's all front end + parse it's trivial.
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.
"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."
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.
I really wish they charged by something other than API requests..as it stands now, I would not even know a reasonable way to pass on the cost to my users.
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.
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 ...
My take on Parse is that they do the grunt work that is necessary with every new project. I am currently building an iPad game on top of parse, and while the pricing is a bit concerning, I figure one of two things will happen:
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...)
With regards to concerns around price: I actually did a comparison between Parse (which I use on some iOS apps) and StackMob, their nearest mobile competitor, and Parse actually came out very well in terms of price (although not so much on some more enterprise level features).
There are two main types of security. Object-level, and app-level. Each object gets access controls that are similar to ACLs in Unix systems. That provides for the sort of security that separates different users' data from each other. On an app-level, you can also control per-class which operations are usable. For more detail, see:
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 protected] and we can help figure something out.
I'm still a little confused by what Parse does and when I would use it. It sounds neat for little, proof-of-concept demos but would I consider it for production of something significant? Does this SDK work without the Parse server?
Parse lets you develop apps without writing any server code. For mobile apps and now also web apps, you can just write frontend code. We have a number of large apps in production using Parse - check out the testimonials at http://parse.com - so you could definitely consider it for significant use.
The pricing seems reasonable, free and then goes up to $200/month once you've gained decent traction. Though it's more than double the cost of a VPS that could support 1 million requests and a 1GB database, and that could make all the difference for an ad-supported app with razor thin margins.
It could also make all the difference in margins because it might prevent you from hiring backend developers at all. that said, I see multiple problems that need to be overcome.
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.
You're ignoring the cost of developing that backend, and maintaining it. That's a significant investment. I don't think Parse is for everyone, but when I've used it on iOS apps the savings I've made from not having to develop the back-end infrastructure is considerable.
It might be exaggerated a bit but the point is valid. You've got enough things to worry about. Do you really want to be sysadmin too?
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.
Yes, this may have been true 10 years ago when installing everything meant getting the source , setting compile flags for everything to work together and updates were applied manually.
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.
Thank you! I read the first sentence: There was a time when building a cutting edge web app meant wasting hours setting up a Linux server, days installing MySQL and Ruby or PHP, and months slaving away writing backend server code.. Huh? I little over the top wouldn't you say!
I'm thinking that this would only work for relatively simple apps though. There might be cases where the functionalities in your apps could only be supported by server-side infrastructure, like uploading files, resizing images, emailing, cron jobs, etc.
What would be really nice is if Parse had a way to somehow plug in existing backend infrastructure to Parse's data model.
This is a great move for Parse! There is some long-term issues about using a service like this, such as: the cost, flexibility, performance, customization, etc.
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.
Yes, you can implement a Disqus-style service with Parse. The SDK uses cross-origin resource sharing to make requests to Parse, so you can host your app anywhere, including on third-party sites.
After looking through the documents I am thoroughly impressed. Parse can handle user management... Are there lots of services out there that does this?!?! I've never figured out an elegant solution to do it with firebase.
Right now, we don't have binary data support (which includes file handling) in Javascript. It's a bit different than Objective-C and Java because Javascript doesn't have great native support for a binary data type. So we can't just expose the same API for binary data that we use for native SDKs. We're working on figuring out a really clean way to support binary data, though.
"There was a time when building a cutting edge web app meant wasting hours setting up a Linux server, days installing MySQL and Ruby or PHP, and months slaving away writing backend server code. Web development was nasty, brutish, and long. It sucked. But that was the past. Parse is the future. And it’s here today."
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?"
I sent the Parse guys a tech-support request on Friday morning before Memorial Day weekend. Most places you send emails to are a black hole and I didn't really expect a response until after the holiday weekend, if at all. To my surprise, I had an answer in my inbox by end of day! This is the kind of support I love in a company. I have not stopped telling everyone I know that they need to check out Parse. They're saving me tons of time getting my next app out the door.
How hard is it really to set up a data model and Rest API using Node/Sinatra/Rails or some equivalent? I agree this is convenient for those with no backend development experience (I know a few who are super stoked about this), however for me I couldn't see giving up control of the server side.
Comparing the JS guide with the iOS and Android guides I see two absences:
1) Files
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?
We want to add both of these features. It will just require a slightly different design than the native mobile versions - files because there is no "binary" type in Javascript, and Facebook/Twitter users are different because integrating with other Javascript libraries is slightly less straightforward than integrating with other native libraries. They should both be possible, though, so stay tuned!
Someone explain what I am missing... I was able to run a simple wget, and I had 100% full functionality of an app (utilizing their API Key, and App ID and all) and run it on my local machine. Data flow is seamless between the local and hosted apps. So while I don't have to worry about a backend, neither does anyone who wants to "borrow" my app. There isn't really any form of app authentication built in that I could find, the REST API master key is the closest thing.
[+] [-] clintjhill|13 years ago|reply
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.
[+] [-] WiseWeasel|13 years ago|reply
[+] [-] lclarkmichalek|13 years ago|reply
[+] [-] cageface|13 years ago|reply
I expect to see an uptick of traffic on exchanges like Flippa as a result of this.
[+] [-] aaronfalloon|13 years ago|reply
[+] [-] arturadib|13 years ago|reply
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.
[+] [-] timjahn|13 years ago|reply
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.
[+] [-] nanijoe|13 years ago|reply
[+] [-] JackC|13 years ago|reply
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 ...
[+] [-] nbclark|13 years ago|reply
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...)
[+] [-] objclxt|13 years ago|reply
http://cleveryou.net/post/22718728512/parse-stackmob-some-th...
[+] [-] tocomment|13 years ago|reply
Sorry if that's a dumb question. I'm still trying to wrap my head around what it is.
[+] [-] taylorbuley|13 years ago|reply
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.
[+] [-] lacker|13 years ago|reply
https://parse.com/docs/data#security
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 protected] and we can help figure something out.
[+] [-] princeverma|13 years ago|reply
[+] [-] pbreit|13 years ago|reply
[+] [-] lacker|13 years ago|reply
[+] [-] guelo|13 years ago|reply
https://www.parse.com/plans
[+] [-] alttab|13 years ago|reply
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.
[+] [-] objclxt|13 years ago|reply
[+] [-] tudorw|13 years ago|reply
[+] [-] tlrobinson|13 years ago|reply
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.
[+] [-] jiggy2011|13 years ago|reply
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.
[+] [-] efa|13 years ago|reply
[+] [-] endlessvoid94|13 years ago|reply
[+] [-] garindra|13 years ago|reply
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.
[+] [-] salimmadjd|13 years ago|reply
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.
[+] [-] JoelMcCracken|13 years ago|reply
I'm wondering if it would be possible to implement a disqus-style service.
[+] [-] lacker|13 years ago|reply
[+] [-] _pius|13 years ago|reply
https://parse.com/tutorials/todo-app-with-javascript
[+] [-] samsnelling|13 years ago|reply
[+] [-] hmans|13 years ago|reply
[+] [-] lux|13 years ago|reply
I don't see examples of file handling through the JavaScript API though, did I just miss it?
[+] [-] lacker|13 years ago|reply
[+] [-] doc4t|13 years ago|reply
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?"
[+] [-] zomgbbq|13 years ago|reply
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] jgannonjr|13 years ago|reply
[+] [-] sargun|13 years ago|reply
[+] [-] lacker|13 years ago|reply
[+] [-] falava|13 years ago|reply
1) Files
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?
[+] [-] lacker|13 years ago|reply
[+] [-] shortj|13 years ago|reply