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 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.
