郑达里

How you want to organize your code is entirely up to you, it seems reasonable I guess. As an alternative approach, I would suggest separating the JSON API server from...

Not yet, I will come up with some examples showcasing a few use cases soon enough. For now there's the tests: https://github.com/fortunejs/fortune/blob/master/test/integration/net/ws_client.js

There's no time interval, it's not polling. It uses WebSocket, so the server actually sends updates to the client at any time during the connection.

By default, yes. However, the server can modify or omit the change before sending anything to clients via the `change` function. If you have a cluster of servers, it gets...

Hey @hamez0r, sorry about delay. Of course it is possible, there might just not be clear documentation or examples for this use case. >For example User A should not be...

>In the typical app with multiple users, each holding their own data, a request to GET /records should only return the records associated with that users. >By the time the...

@cecemel, >To me, it seems that fetching data from the DB is different from presenting data to the client. Yes, this is by design. So you can do it that...

@mattcollier Fortune.js denormalizes all relationships. So you could do something like: ``` store.find('B', null, null, ['F', 'D']) store.find('C', null, null, ['E', 'F', 'D']) ``` It actually doesn't matter where you...

Hi, sorry for delay. Yes, I would recommend calling `store.disconnect`, changing the record type definitions on `store.recordTypes`, then reconnecting with `store.connect`. Reconnecting isn't really necessary, just advised for some adapters...

It's intended behavior that the error appears again from the listener function. Internally the error gets caught and thrown again. This makes it possible to correlate the Node.js HTTP request...