Thanks, I hadn’t heard about Falcor, and it looks pretty great. Not yet sure how complicated building the client router for our rest api would be (in addition to tying falcor into angular), but I’ll definitely keep looking into it.
Taking this topic in the opposite direction - Let’s say scalability and caching aren't the biggest concerns for my project. (90% of the expected users will have pretty small run-time data sets) Are there good reasons not to fashion state specific request apis that don’t hinge on a rigorous client model? Obviously, my business logic would be restrained to individual states, but is that really a problem if my application is pretty much a 1:1 between states and specific actions? > On Jun 27, 2016, at 3:30 PM, 'Lucas Lacroix' via AngularJS > <[email protected]> wrote: > > We have had similar conversations in my current project. > > We came up with the concept of an "aggregate" API, which is, actually, very > akin to graphQL/Falcor. Essentially, the client already knows about the > relationships between objects and can issue a single call to a special API > which will combine all or some of the data from several other API calls. This > means the client can obtain all the data it needs for a view with a single > round-trip. > > Example: > Given this basic API calls and return values: > v1/user/userA/ => { > "name": "userA", > "supervisor": "v1/user/userB" > } > > v1/user/userB/ => { > "name": "userB" > } > > Now we want to get userA and also userA's supervisor, so we might issue a > call to the aggregate API like: > { > "get": { > "url": "v1/user/userA/", > "id": "user" > }, > "replace": { > "userA.supervisor": "deference(userA.supervisor)" > } > } > > And get back: > { > "name": "userA", > "supervisor": { > "name": "userB", > } > } > > It does have a down-side however: the client cannot cache the individual > pieces of data (well, it could, but it wouldn't be easy to create a > generalized mechanism) which means every aggregate API invocation which > includes a reference to "userB" would receive "userB"'s data in the payload. > However, in our case, because of the sensitivity of our data, caching is a > huge no-no anyways, so we're not worried about the performance impact of > repeatedly getting all/some of the same data. > > -Luke > > > On Mon, Jun 27, 2016 at 6:11 PM, Jonathan Price <[email protected] > <mailto:[email protected]>> wrote: > I'm having a tough time figuring out the best path for modeling server data. > Up to now, I've had luck using classes that contain related data and > functionality and a manager for each of these classes that monitors the pool > of classes I've downloaded from the server. The problem I'm running into is > within more complicated views that need access to nested relationships of > these objects. Like Object A has an id reference to 3 other classes - so now > I've got to go hit three other managers to find the related properties for > Object A. I'm basically left doing per-view object compositions. > > I'm trying to formulate some possibilities that seem like they will scale in > the future, and I keep coming back to the idea of ditching these class models > entirely and handling the server data on a per-view basis - i.e. no > consistent model. > > Can any of you offer design suggestions, pros and cons or examples? > > Thanks, > Jonathan > > -- > You received this message because you are subscribed to the Google Groups > "AngularJS" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > Visit this group at https://groups.google.com/group/angular > <https://groups.google.com/group/angular>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. > > > > -- > Lucas Lacroix > Computer Scientist > System Technology Division, MEDITECH <http://ehr.meditech.com/> > 781-774-2293 <tel:781-774-2293> > > -- > You received this message because you are subscribed to a topic in the Google > Groups "AngularJS" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/angular/CC0MOQKjwrc/unsubscribe > <https://groups.google.com/d/topic/angular/CC0MOQKjwrc/unsubscribe>. > To unsubscribe from this group and all its topics, send an email to > [email protected] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > Visit this group at https://groups.google.com/group/angular > <https://groups.google.com/group/angular>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- You received this message because you are subscribed to the Google Groups "AngularJS" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/angular. For more options, visit https://groups.google.com/d/optout.
