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.

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.

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.