Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Parse launches JavaScript SDK: Parse for Websites

blog.parse.com

Post reply on HN
Print view View original

91–100 of 112 posts

Re: Parse launches JavaScript SDK: Parse for Websites

#91

Post by nupark2 »

lclarkmichalek wrote: post #87
reinhardt wrote: post #65

Earlier quoted context omitted.

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

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.

Re: Parse launches JavaScript SDK: Parse for Websites

#92

Post by nupark2 »

tlrobinson wrote: post #70
tudorw wrote: post #7

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.

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.

Re: Parse launches JavaScript SDK: Parse for Websites

#93

Post by rapind »

lacker wrote: post #77
rapind wrote: post #72

Earlier quoted context omitted.

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…

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" secti…

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!

Re: Parse launches JavaScript SDK: Parse for Websites

#94

Post by lacker »

rapind wrote: post #93
lacker wrote: post #77

Earlier quoted context omitted.

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" secti…

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

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.

Re: Parse launches JavaScript SDK: Parse for Websites

#95

Post by alttab »

agotterer wrote: post #64
alttab wrote: post #31

Earlier quoted context omitted.

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

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.

Re: Parse launches JavaScript SDK: Parse for Websites

#96

Post by cageface »

clintjhill wrote: post #14

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…

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.

Re: Parse launches JavaScript SDK: Parse for Websites

#97

Post by neilparikh »

meaydinli wrote: post #82

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

Re: Parse launches JavaScript SDK: Parse for Websites

#98

Post by kenrikm »

nupark2 wrote: post #91
lclarkmichalek wrote: post #87

Earlier quoted context omitted.

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

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, t…

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.

Re: Parse launches JavaScript SDK: Parse for Websites

#100

Post by kenrikm »

mortenjorck wrote: post #61
jiggy2011 wrote: post #21

Earlier quoted context omitted.

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

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.

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