Could you state the question in another way? I'm having difficulty understanding with the double negatives and jargon.
On Mon, Jun 27, 2016 at 10:19 PM, Puritan Paul <[email protected]> wrote: > 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]> > 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]. >> 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. >> > > > > -- > Lucas Lacroix > Computer Scientist > System Technology Division, MEDITECH <http://ehr.meditech.com/> > 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. > To unsubscribe from this group and all its topics, 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. > > > -- > 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. > -- Lucas Lacroix Computer Scientist System Technology Division, MEDITECH <http://ehr.meditech.com> 781-774-2293 -- 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.
