Data model difficulties

[Jonathan Price]

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

[Lucas Lacroix]

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

--
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 angular+u...@googlegroups.com.
To post to this group, send email to ang...@googlegroups.com.
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

781-774-2293

[Puritan Paul]

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?

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 angular+u...@googlegroups.com.

[Lucas Lacroix]

Could you state the question in another way? I'm having difficulty understanding with the double negatives and jargon.