
App Engine JavaScript SDK - danh
http://www.appenginejs.org/
======
axiom
If you're thinking of using the App Engine read this first:

[http://highscalability.com/blog/2010/5/26/end-to-end-
perform...](http://highscalability.com/blog/2010/5/26/end-to-end-performance-
study-of-cloud-services.html)

~~~
koenbok
But read it well. It seems AppEngine comes out very bad, but it was tested for
db transaction speed in a way that every insert locks the entire db (one big
entity group). Any AppEngine developer could tell you not to use it like this.
More info:
[http://code.google.com/appengine/docs/python/datastore/keysa...](http://code.google.com/appengine/docs/python/datastore/keysandentitygroups.html)

It would be very interesting to see what the results would be with some more
realistic testing.

~~~
bad_user
> _Any AppEngine developer could tell you not to use it like this_

I'd really wish for some AppEngine developer to tell me how's the proper way
of designing entity groups. The only advice given is to not exceed a single
user's data, otherwise it's too big.

Really, I want to see an example of a request handler that creates data in
multiple entities and takes care to not create duplicates.

> _It would be very interesting to see what the results would be with some
> more realistic testing._

IMHO, my experience with AppEngine's datastore has been pretty bad ... the
performance varies greatly based on factors you can't control ... i.e.
processing something that does well on slow Fridays, may throw the 30 secs
timeout error on Mondays.

Also, I don't know how people deploy real-world apps on it ... a non-
relational datastore requires custom indexes (i.e. precalculated queries done
by building specialized entities out of your quasi-normalized data).

You can't do that easily because of the 30 secs limit that also applies to
cron or queue jobs. I tried a workaround by having a queue task that processes
5 rows at a time and then reschedules itself. The stuff was so god-damn awful
to debug, and the results so unpredictable (30 secs timeout for 5 rows /
concurrency issues) that I felt like crying.

But yeah, it's fine for hosting a blog engine on top of it.

~~~
axiom
Another issue we're running into now (as a result of having a growing number
of users) is that we're noticing that downtime on the App Engine is shockingly
bad, and getting worse.

Over the last few weeks, we've seen periods of downtime pretty much daily, and
serious downtime (i.e. more than a few minutes) monthly. It's grossly under-
reported in the App Engine status console, which shows a euphemistic warning
(which in practice might mean that all server requests will return errors.)

Our software is used in the classroom during lectures, and we've had several
customers experience system failure due to App Engine downtime. On top of that
we've had more than one customer demo go wrong for the same reason.

It's pretty infuriating actually, because 1. you can't do anything other than
just sit there and wait it out, and 2. there is no one to talk to at Google.
Finally, the problems are only getting worse.

We were going to do a slow migration out of the App Engine over the course of
a few months (because we've got a ton of code to rewrite.) At this point we're
doing an emergency 2 week migration with all devs pulled from their projects
for the task.

I honestly have no idea why these issues aren't getting more mainstream
attention, given how many people are using the App Engine. The only thing I
can come up with is that there must be tons and tons of tiny non-critical
projects, and very few serious startups betting their business on the App
Engine.

~~~
hamstersoup
I was about to start a big project on App Engine, so your comment is worrying.

Anybody else having reliability problems with GAE or is this just an isolated
case?

~~~
axiom
If you're interested in more gory details feel free to email me at mike at
tophatmonocle dot com.

For what it's worth, we're an angel funded startup with some extremely bright
hackers and we were signing praises about the App Engine until about 3 months
in, when we started hitting it's various brick walls.

Oh, and take a look at: <http://code.google.com/status/appengine>

Click through the various items with green checkmarks to see the actual data
that GAE considers "no significant issues." Including fun stuff like 80%
datastore error rates.

~~~
gmosx
There might be some problems but it's great to know that Google system
administrators (instead of me) are taking care of it. When I hosted my
application on EC2 twice I almost lost all my files due to hardware problems.
I had to spend all night preparing a new server, _not_ funny. There are no
servers to fail in App Engine, I _love_ that!

------
pmjordan
I'm always amazed at how popular Rhino is vs. how little active development
effort it receives. I'm as guilty as anyone of course.

~~~
monos
the thing about rhino is, that it already _is_ a mature js implementation. it
has the most modern js support of all the engines out there (the version
shipping with java is sadly quiet old) and it's battle tested. we have it in
production since 8+ years.

i can see how it might seem rhino has "little active development" because we
are comparing it to js implementations that just started and of course have
more "going on" then the old horse.

~~~
pmjordan
The general consensus seems to be that Rhino doesn't really exploit the
performance potential of the JVM. Basically, it could probably be a lot
faster.

------
gmosx
some more thoughts on appengineJS here:
[http://www.gmosx.com/blog/agVnbW9zeHIPCxIHQXJ0aWNsZRipwwEM/o...](http://www.gmosx.com/blog/agVnbW9zeHIPCxIHQXJ0aWNsZRipwwEM/on-
appenginejs)

------
AlexisT
Great stuff!

------
agentultra
Cool project. I'll never understand why anyone wants to program in JS though.

~~~
artlogic
I used to feel this way. The two people that changed my mind were John Resig
and Douglas Crockford. Resig's jQuery project has been, for me, a guide to how
JS should be written. Crockford's JS the Good Parts and JSLint have helped as
well by providing some solid reference on what to do and, more importantly,
what not to do.

Lots of folks only see the DOM and the bad parts when working with JS - these
two projects have shown me there's so much more.

~~~
orangecat
_Lots of folks only see the DOM and the bad parts when working with JS_

Agreed that you can't blame Javascript for the DOM, but there are _lots_ of
bad parts aside from that. Default global scope and semioptional semicolons
are gigantic WTFs, the with statement should be nuked from orbit, and there
are generally lots of ways to write code that appears to be correct but is
just waiting to fail in bizarre ways. It's just annoying that we're stuck with
Javascript because it's so entrenched, while Python and Ruby offer all of its
strengths in much saner packages.

~~~
artlogic
I believe I did say "and the bad parts". I agree - there are lots of bad parts
to JS - I often wish it could be remade without the bad parts. However, a lot
of these bad parts can be mitigated with sane conventions - that's what
Crockford's "Good Parts" is all about. If you haven't read it, I highly
suggest it.

I can't speak for Ruby, but in many ways JS is more powerful than Python,
especially on the functional side of the house.

