Live data from Hacker News

Parse launches JavaScript SDK: Parse for Websites

blog.parse.com

81–90 of 112 posts

Re: Parse launches JavaScript SDK: Parse for Websites

#81

Earlier quoted context omitted.

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 w…

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.

Re: Parse launches JavaScript SDK: Parse for Websites

#83

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 th…

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 ...

Re: Parse launches JavaScript SDK: Parse for Websites

#84
post #30

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…

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...

Re: Parse launches JavaScript SDK: Parse for Websites

#85
post #20

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

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.

Re: Parse launches JavaScript SDK: Parse for Websites

#86

Earlier quoted context omitted.

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 w…

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 a…

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.

Re: Parse launches JavaScript SDK: Parse for Websites

#87

Earlier quoted context omitted.

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.

Re: Parse launches JavaScript SDK: Parse for Websites

#88

Earlier quoted context omitted.

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.

Re: Parse launches JavaScript SDK: Parse for Websites

#89

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 - i…

It'll be awesome for prototypes!

Re: Parse launches JavaScript SDK: Parse for Websites

#90

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 - i…

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.
Post reply on HN