Comment by mikelehen | Hacker News Reader

Comment by mikelehen | Hacker News Reader

Parent Full thread

1. The API was designed pretty carefully to ensure we wouldn't box ourselves into any corners that would limit our real-time or scalability capabilities. So we've intentionally avoided advanced querying for now. You may see features along these lines in the future, but right now we recommend denormalizing your data during writes to match how you want to consume the data (which is a pretty common nosql practice). Firefeed is a good example of this, actually.

2. RequireJS is on our radar. I don't know too much about it, but if developers want it, we'll likely end up adding it. :-)

Regarding #2, to register as a module you just need something like this:

https://github.com/umdjs/umd/blob/master/amdWeb.js

On the denormalization front, is it possible to do transactions without locking / syncing the entire tree. I'm thinking friendship modeling like:

  user1.friends = ['user2']
  user2.friends = ['user1']

Transactions have to be done at the common ancestor of the data being modified, so it's best to use them for data that's nearby in the Firebase data tree. You /can/ do a transaction on a large chunk of data (e.g. the entire user list), but the client would need to sync the entire data and there'd be a greater chance of contention.

If you need atomic bidirectional friendships though, you can do it if you structure your data a little differently. To turn a friendship between a pair of users on and off, you could set /friends/user1/user2 to true iff user1 and user2 are friends. Then you can write security rules that are based off of that to allow and deny access to the users' data.

Reply on news.ycombinator.com