1

I wonder, if the below idea makes sense for our web application. We show various lists of entities, which typically refer to other entities and so on. In the table view, there are columns showing some properties of the entity itself (like e.name) and also of the linked entities (like e.owner.email).

The classical way is to create DTOs containing all these columns and sent them. This means that for any column added, there need to be a (trivial) change on the server. There's also a bunch of redundancies, as many linked entities are the same. For example, e.owner is nearly always the same, as (with some exceptions) everyone can see their own entities only.

So my idea was to send JSONized entities, where the references get replaced by their IDs and additionally send a list of the referenced entities. This all recursively, so for the object graph

[
    {
        id: 101,
        name: "something1",
        company: {
            id: 201,
            name: "someCompany"
            owner: {
                id: 301,
                firstName: "Bart",
                lastName: "Simpson"
                email: "bart.simpson@example.com",
            }
        }
    },
    {
        id: 102,
        name: "something1",
        company: {
            id: 201,
            name: "someCompany"
            owner: {
                id: 301,
                firstName: "Bart",
                lastName: "Simpson"
                email: "bart.simpson@example.com",
            }
        }
    },
]

instead of

[
    {
        id: 101,
        name: "something1",
        company_name: "someCompany",
        company_owner_firstName: "Bart",
        company_owner_lastName: "Simpson",
        company_owner_email: "bart.simpson@example.com",
    },
    {
        id: 102,
        name: "something2",
        company_name: "someCompany",
        company_owner_firstName: "Bart",
        company_owner_lastName: "Simpson",
        company_owner_email: "bart.simpson@example.com",
    },
]

I'd send

{
    entities: [
        {
            id: 101,
            name: "something1",
            company: 201,
        },
        {
            id: 102,
            name: "something2",
            company: 201,
        }
    ],
    companies: [
        {
            id: 201,
            name: "someCompany"
            owner: 301,
        }
    ],
    owners: [
        {
            id: 301,
            firstName: "Bart",
            lastName: "Simpson"
            email: "bart.simpson@example.com",
        }
    ],
}

and let the client re-combine the things when displaying the result. This could lead to nice bandwidth savings (not visible in this tiny example), but this is probably what Content-Encoding: gzip achieves anyway.

The next step could be some caching on the client, so that only changed and/or new entities would be sent. This could save much more. The implementation overhead is surely non-trivial, but I'm sure it can be done in a day or two.

My questions:

  • Is there already anyone doing this?
  • Is it a good idea?
  • There is almost certainly someone out there doing this. It's a good idea if it meets your software's requirements better. – Robert Harvey Apr 28 '16 at 17:43
  • Yes. I do this a lot. Often you need to do.something like populate a drop down And show the selected detail on a list of entities. – Ewan Apr 28 '16 at 17:47
2

It's certainly being done, but I think whether it's a good idea depends on the style and size of application.

  1. How big is this application and how long will it live? It's harder to trace behavior and refactor with a very long path of code that might rely on the object-properties and relationships, meaning it has to be inspected and fixed as a unit. (As opposed to thinner tiers.)

  2. How much are you willing to trust the client with raw data? How complicated are the "privacy rules" for stripping (or replacing) object properties which shouldn't be visible?

  3. You'll always have something that doesn't fit into the model, like fast and efficient listing-pages. You won't be able to fit everything into this style, so make sure you're comfortable maintaining the old way too.

I think it's a good fit for an application where you're fine pushing lots of logic to the client/UI level, and you trust the client (and the user) with freedom to rewrite and change whatever the data is. If it's part of a larger application, then it's "walled off" behind some kind of load/save step that applies other business-logic on the server-side.

However, if you're working on a big application that has a lot of server-side rules, then I would at least have a very clear translation-boundary between "the server-side objects" versus "the JSON object graph".

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.