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?
[deleted]
Parse launches JavaScript SDK: Parse for Websites
51–60 of 112 posts
Re: Parse launches JavaScript SDK: Parse for Websites
#52Earlier 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();}
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.
Re: Parse launches JavaScript SDK: Parse for Websites
#53How 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.
Re: Parse launches JavaScript SDK: Parse for Websites
#54I'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…
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).
Re: Parse launches JavaScript SDK: Parse for Websites
#55Earlier quoted context omitted.
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 po…
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).
Re: Parse launches JavaScript SDK: Parse for Websites
#56Now 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 :)
Re: Parse launches JavaScript SDK: Parse for Websites
#57Earlier quoted context omitted.
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.
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'…
(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
Re: Parse launches JavaScript SDK: Parse for Websites
#58Earlier quoted context omitted.
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'…
(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…
Will follow-up with you...
Re: Parse launches JavaScript SDK: Parse for Websites
#59Earlier quoted context omitted.
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 po…
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.
Re: Parse launches JavaScript SDK: Parse for Websites
#60seriously, if it took you days to set up PHP and MYSQL you might have picked the wrong vocation...
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!