Parse launches JavaScript SDK: Parse for Websites(blog.parse.com)
blog.parse.com
Parse launches JavaScript SDK: Parse for Websites
http://blog.parse.com/2012/05/30/parse-launches-javascript-sdk%3A-parse-for-websites/
33 comments
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.
I downloaded the todo app, modified it to skip signup and login, added my own keys to Todo and saved successfully. Changed the class name and saved successfully. For what kind of app would this be OK even if users were authenticated? Data coming from a client must have a predefined, server validated schema to be useful in any real world app and business logic cannot be in the hands of the user. Am I missing something?
Love this but running this JavaScript SDK in IE is a bit tricky. Basically, if you would like your solution to support 50% of internet users you would be forced to run your HTML/JS solution in a SSL-enabled server. I hope they enable a non-SSL solution soon. Oh! and forget about IE7 or IE6 users.
One question to the Parse department: How do you add indecies to fields? Do you automatically create them?
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?
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?
yep, database indices are created for you automatically. This is one of the details we hope app developer should never worry about.
[deleted]
amazing because I wrote something similar few weeks ago. It's based on Backbone though. github.com/neebz/backbone-parse
Beautiful website.
Can anyone explain to me how authentication works with JS-based storage client like this?
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.
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.
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:
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.
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.
I still don't get how I, as a malicious (or curious) user with some form of write permission, would be prevented from doing the equivalent of opening up Firebug console and typing while(true){var p = new Post(); p.save();}
Presumably it is exactly the same as in any other web application--the save method is using an HTTP request under the covers, which must be rejected if the user is not authorized to perform that action.
I don't think it's just a matter of authorization. I think you would have to use something like anti-forgery tokens to prevent automated scripting of http requests.
[deleted]
What prevents you from doing this with ajax post on every existing website?
Server-side logic. The difference is that traditional data flow is UserControlledCode (i.e. client-side JS) --> MyServer --> DataStore, whereas this is UserControlledCode --> DataStore. In practice you may often choose not to have the code in MyServer do anything beyond act as a pass-through, but not having that option at all seems scary. The only recourse I see is things like database schema constraints (e.g. max posts per user = 10), but that doesn't really solve the problem.
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.
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.
Another way of wording his (and my) concern is how do you securely identify the user? Nevermind the permissions model (ACL), how do you actually ensure the user is who they say they are, and how tamper-proof is this authentication.
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.
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.
For secure user identification we have the typical username/password model. You don't have to expose that to end users, so you can also cross-authenticate with your own systems. The password is only stored on the server, with a client-side token. There's more documentation for this here:
https://www.parse.com/docs/js_guide#users
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.
https://www.parse.com/docs/js_guide#users
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.
Great. I actually read through the "Users" section and didn't see anything about the client-side authentication token.
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!
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!
Actually, the Javascript SDK handles the auth token for you. Once you have successfully completed a logIn or signUp, the token is stored in localStorage until logOut is called. And then it is passed along with subsequent requests to authenticate. So, you don't need to worry about how many characters the token is, or things like that.
We should definitely make the documentation clearer on this point, because this is all stuff that should Just Work.
We should definitely make the documentation clearer on this point, because this is all stuff that should Just Work.
I have a question: Is there a possibility to "disable" the automatic creation of new classes? because if I understand the documentation right, then it would be possible for any user to spam my model with new classes.
Note that, as far as I can see, Classes are a SDK convenience but the data itself is completely schemaless as far as the Parse backend is concerned.
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.
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.
This has always been my concern (perhaps naive) with any (not just this) javascript SDK. It seems that it would be very easy, and almost inviting, for a malicious user to script a spam attack using the javascript console in their browser, and perform a large number of inserts to the database before you can detect this and disable their account.
Are there common javascript development practices or conventions to prevent malicious users from writing an infinite loop (as pseudo-coded in the post above) and spamming your data set?
Are there common javascript development practices or conventions to prevent malicious users from writing an infinite loop (as pseudo-coded in the post above) and spamming your data set?
I can't see it working well in a game scenario, but the vast majority of CRUD apps out there could be safely implemented using Parse's security model (as described in lacker's link).
They use a game in their JS documentation! And as they wrote it it's totally vulnerable to the user incrementing their own score.
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.
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.
I think this is the answer from their docs:
--------------------
All operations are still possible when authenticating with the master key via the REST API. As a developer, this lets you manage any aspect of the data. For example, you can delete private messages via the REST API even if they are private based on the ACL.
------------------------------------
So you really need a intermediate and secure server if you are doing something that needs to be trusted. To have a game completely offline would be a recipe for disaster.
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.
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.
Yeah -- but I think a service that offers to handle all the server stuff for you that also requires you to set up a server has missed a step somewhere.
This is true, but at least if you control your own backend you can do some sort of rate limiting on the server side
[deleted]
I am wondering same thing, can somebody explain this please.
It's relatively easy to do basic HTTP authentication using Javascript. If you're on SSL, that's reasonably secure. Once you're authenticated the server can issue a nonce that identifies you and gives you authorization (role-based access) to various pages/objects/apps based on that nonce.
Absurdly lame opening paragraph. Made me want to use Parse a little bit less.
Man, this is awesome. You can now basically host a full web app completely through a CDN.
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.
Edit : I take it back. Parse has a REST API.
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.
You can use their REST API. It's really well made and I've done a few smallish projects using it.
Annnd you just said that. Didn't see your edit heh.
Annnd you just said that. Didn't see your edit heh.
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.
seriously, if it took you days to set up PHP and MYSQL you might have picked the wrong vocation...
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.
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.
I see Heroku, Beanstalk, et al as the future here. This code-less approach will hit a brick wall very quickly, at which point they'll be writing something not unlike Google AppEngine, which itself suffers from being proprietary.
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.
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.
Well, sure, LAMP is easy to set up if you're working in PHP; that's one of the huge advantages PHP has over most other options. You want to set up and deploy to a Rails server, though, that's going to be a bit more effort.
>You want to set up and deploy to a Rails server, though, that's going to be a bit more effort.
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.
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.
I've actually had an easier time setting up Phusion Passenger with Apache than I've had setting up PHP. Ease of deployment isn't necessarily a major advantage in PHP's corner anymore.
Like Phil said, it doesn't take more than an hour if you're feeling lazy about it. I've automated it with Chef, but I haven't timed it or anything. Less than 10 minutes for sure.
Rails is not the difficult after you have done it a few times, just line up your console commands and get to work most of the time is waiting for stuff to download/compile.
Not too much more difficult , reverse proxying with apache is only a few lines in the conf file.
Days/Months of effort?
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!
Really awesome. I appreciate the fact that the tutorial starts off by addressing authentication.
https://parse.com/tutorials/todo-app-with-javascript
https://parse.com/tutorials/todo-app-with-javascript
if I never see another fork-tongued ribbon with the stitching and the little stars, it will be too soon
Anyone know if it would be possible to implement generic javascript-based "apps" for any websites?
I'm wondering if it would be possible to implement a disqus-style service.
I'm wondering if it would be possible to implement a disqus-style service.
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.
Really nice. That is an interesting use case.
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 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).
All proprietary APIs. Also not all APIs are as critical and large encompassing as the whole backend code of your business.
Many are very critical, and many are not proprietary. Databases and web frameworks are two that come to mind immediately, yet people seem to choose those based on the number of blog posts about them. And almost all APIs are vulnerable to reimplementation. With Parse's API, it would theoretically be possible for another project to implement an identical interface to their backend, and allow you to simply change one LoC in your application to change the provider of your BaaS.
There's a substantial difference between a service and an installed product.
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.
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.
A few points I would like to make:
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.
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.
> 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.
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.
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.
And not all APIs are startups with a decent likelihood of not being around in the future.
His argument was about the fact that you're stuck using their APIs on their servers. This doesn't really apply to all APIs.
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.
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.
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.
I expect to see an uptick of traffic on exchanges like Flippa as a result of this.
It'll be awesome for prototypes!
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.
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 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.
OK, I looked at it in more depth than I usually do and I can see that there would be a decent number of use cases. But as another posted said, on one hand it looks like a great platform to build against, on the other it seems really dumb to do so (locked in, etc).
Perhaps someone could reverse engineer the APIs and provide a Python/Rails + DB back-end.
Perhaps someone could reverse engineer the APIs and provide a Python/Rails + DB back-end.
As am I. I'm hoping someone will chime in and get us low tech folks updated.
[deleted]
[deleted]
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.
https://www.parse.com/plans
https://www.parse.com/plans
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.
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.
Curious, what would they need to offer for you to consider it for a functioning business? An easier way to get the data out, an SLA, what?
The problem is a growing business won't initially understand where the real technical requirements are.
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.
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.
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.
Hats off.
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.
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 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.
Whats wrong with estimating the number of API requests the average user makes and figuring out a price based on that?
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 ...
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 ...
"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?"
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?"
how does this compare/contrast with Firebase?
[deleted]
Was just thinking this was the next logical move for Parse to really blow up. Nicely done too!
I don't see examples of file handling through the JavaScript API though, did I just miss it?
I don't see examples of file handling through the JavaScript API though, did I just miss it?
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.
Good to know it's in the works! Definitely a messy problem with current browser limitations.
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...)
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).
http://cleveryou.net/post/22718728512/parse-stackmob-some-th...
http://cleveryou.net/post/22718728512/parse-stackmob-some-th...
How does parse save you time building your ipad game?
Sorry if that's a dumb question. I'm still trying to wrap my head around what it is.
Sorry if that's a dumb question. I'm still trying to wrap my head around what it is.
A few things:
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.
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 was going to write you offline but you do not have an email associated with your HN account.)
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 [1]
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".
[1]: http://ishamrock.com/post/20122762136/words-play-reflections... rs-turn-based
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 [1]
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".
[1]: http://ishamrock.com/post/20122762136/words-play-reflections... rs-turn-based
Will follow-up with you...
It would probably work pretty well for a game based around creating and sharing levels.
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?
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!
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.
[deleted]
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.
Now I'm waiting for someone to create a service where I don't have to waste my time with HTML+JS+CSS and focus on the application core :)
You cant write anything serious with this, for any business processing, where the interesting things happen, you need your own servers, not just storage and you cant trust the clients with your processing needs. For example, make a VPN service out of this, or a file sharing application with payment system?
Yay, more Parse spam.
Can some one please compare stackmob and parse and any other competitors they have? I recently started using them, and I'd appreciate your thoughts.
Haven't read through it myself, but some one posted this comparison: https://news.ycombinator.com/item?id=4044943