

Parse launches JavaScript SDK: Parse for Websites - jamesjyu
http://blog.parse.com/2012/05/30/parse-launches-javascript-sdk%3A-parse-for-websites/

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

~~~
lclarkmichalek
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).

~~~
reinhardt
All _proprietary_ APIs. Also not all APIs are as critical and large
encompassing as the whole backend code of your business.

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

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

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

~~~
nupark2
> _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.

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

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

~~~
lopatin
Whats wrong with estimating the number of API requests the average user makes
and figuring out a price based on that?

~~~
nanijoe
How do you do that without first having the users make the API calls, at which
point you are already using the service and the estimate is useless..

~~~
agotterer
What do you think could be an alternative? By backed/service that you
interface with?

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

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

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

~~~
fictorial
(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...](http://ishamrock.com/post/20122762136/words-play-reflections-
on-game-cente) rs-turn-based

~~~
nbclark
Will follow-up with you...

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

~~~
lacker
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 feedback@parse.com and we can help figure something out.

~~~
peripitea
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();}

~~~
equark
What prevents you from doing this with ajax post on every existing website?

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

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

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

~~~
rapind
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!

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

------
pbreit
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?

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

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

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

~~~
agotterer
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?

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

------
tudorw
seriously, if it took you days to set up PHP and MYSQL you might have picked
the wrong vocation...

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

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

------
endlessvoid94
Man, this is awesome. You can now basically host a full web app completely
through a CDN.

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

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

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

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

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

~~~
JoelMcCracken
Really nice. That is an interesting use case.

------
_pius
Really awesome. I appreciate the fact that the tutorial starts off by
addressing authentication.

<https://parse.com/tutorials/todo-app-with-javascript>

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

------
hmans
Absurdly lame opening paragraph. Made me want to use Parse a little bit less.

------
lux
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?

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

~~~
lux
Good to know it's in the works! Definitely a messy problem with current
browser limitations.

------
doc4t
"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?"

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

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

------
sargun
Congratulations guys, this is cool stuff. How's your backend / infrastructure?
Are you still a MongoDB shop?

~~~
lacker
We use MongoDB for some data, but we also use MySQL and Redis. Really it's a
question of using the right tool for the job.

------
falava
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?

~~~
lacker
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!

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

------
jasonkostempski
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?

------
krzyk
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 :)

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

------
nchuhoai
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?

~~~
andwang
yep, database indices are created for you automatically. This is one of the
details we hope app developer should never worry about.

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

~~~
neilparikh
Haven't read through it myself, but some one posted this comparison:
<https://news.ycombinator.com/item?id=4044943>

------
DrCatbox
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?

------
dmvaldman
how does this compare/contrast with Firebase?

------
neebz
amazing because I wrote something similar few weeks ago. It's based on
Backbone though. github.com/neebz/backbone-parse

------
prezjordan
Beautiful website.

------
DavidAbrams
Yay, more Parse spam.

------
liamondrop
if I never see another fork-tongued ribbon with the stitching and the little
stars, it will be too soon

