Array of objects vs Object of Objects

Question

The issue is to decide the trade offs between the following notations:

JSON based:

"users": {
    "id1": {
        "id": "id1",
        "firstname": "firstname1",
        "lastname": "lastname1"
    },
    "id2": {
        "id": "id2",
        "firstaame": "firstname2",
        "lastname": "lastname2"
    }
}

Array Based:

users: [
    {
        "id": "id",
        "key2": "value2",
        "key3": "value3"
    },
    {
        "id": "id",
        "key2": "value2",
        "key3": "value3"
    }
]

Relating to this post on the same issue, I have decided (on front end) to use the JSON object notation instead of an array of objects as it suits my requirements, provides better performance, and results in less code in the browser.

But the problem is that the list itself is not static. By this I mean the list is being generated i.e. fetched/stored from DB (NoSQL) and created for new entries through a Java API on the server. I am not able to decide on which notation I should use at the back end (which eventually will also affect the UI too).

Any thoughts/suggestions about performance, maintainability or scalability is appreciated.

Answer 1

This is a totally subjective question. There might be many other points, but let me point out a few below:

JSON based approach: If I am not wrong then this will be implemented using Map on server side.

Advantage: In JavaScript you can directly use users.id1, users.id2, i.e. no need of iteration

Disadvantage: On the client side, somehow you will need the ids to be present in your JSON, i.e. either hard coding them or using some dynamic approach which will tell you which id is present in your JSON.

---

Array Based approach: If I am not wrong then this will be implemented using Array/List on server side.

Advantage:

1. On client side, you can directly iterate through array, without worrying in advance about which id is present inside it i.e. no hard coding.
2. As pointed out by @JBNizet, the array based approach will maintain the order.

Disadvantage: If you want to fetch single id then you will need to iterate through the array.

Generally we don't send much information on the client side, so array based approach will not create any problem. And transforming an array into a map is possible on both sides (server and client) if you want an id based approach.

Answer 2

On the server side, Arrays are stored as simple Lists: ArrayList<Content>, while Objects are either stored as maps: HashMap<String, Content> or, mostly, as Java Objects.

In order to convert Java Entities to and from JSON, you can take a look at the Jackson project which does all that for you.

I wouldn't worry about any performance differences between those two variants. It's more important to have an understandable, semantic API, so you should base your decision on the business case rather than performance.

Looking at your example, I think an Array is the better approach, since you want to return a list of users which are all equal. Sending the id twice makes no sense imho and increases the amount of data that has to be transmitted.

Furthermore, since Arrays are much simpler to store and to iterate in Java, they should also provide better performance than Objects.

Some general differences:

• Arrays preserve the order
• Arrays can contain duplicate entries
• Objects often have a bigger storage/network overhead
• Arrays are faster to iterate (on the server side)

Answer 3

Along with all the above technical differences, I think there is a fundamental difference in the purpose and meaning of an Object and an Array.

1. The properties of an object DESCRIBE/DEFINE the object whereas
2. The elements of an array do NOT DESCRIBE/DEFINE the array, on the contrary, the array defines what its contents are. Do note - I am not talking about technical aspects. You can have any combinations technically but semantically each has its own purpose.

• For example a card holder. Each card does NOT DESCRIBE/DEFINE the cardholder. But the cardholder does define its purpose - that it holds only cards.

• An Object is used to represent an entity and its properties DESCRIBE/DEFINE the entity. Take the same example of a Card. A card has properties like color, number which DESCRIBE/DEFINE what the card is.

For your above example:

1. Each object which represents a person is defined by the properties id, firstName, and lastName.

2. A list of these persons cannot be an object of objects because each id does not describe the object of objects. So

"users":[
    {
        "id": "id",
        "key2": "value2",
        "key3": "value3"
    },
    {
        "id": "id",
        "key2": "value2",
        "key3": "value3"
    }
]

is a better representation than

"users": {
    "id1": {
        "id": "id1",
        "firstname": "firstname1",
        "lastname": "lastname1"
    },
    "id2": {
        "id": "id2",
        "firstaame": "firstname2",
        "lastname": "lastname2"
    }
}

even though technically you can use either. I hope I was able to convey (put into words) my thinking in the proper manner.

Answer 4

You can use object[property] notation to access or set properties in an object in JavaScript.

Go with array based approach at the backend, and convert the array to a map (JSON based as you refer to it) in the front end.

var list = [{id: "id1", value: "One"}, {id: "id2", value: "Two"}]
var map = {};
list.forEach(function (item) { map[item.id] = item });
map.get("id1")

If your list changes, you can get the new list from backend and update your map in UI.

This way your backend is faster to respond as it does not have to convert list to a map. Your front end will do a O(n) iteration once over the list to convert it to a map. But that is a small price compared to O(n) you will pay every time you search on a list.

If you will be doing get by id predominantly on your data at the back end go with JSON Based at the backend itself (you can use LinkedHashMap to preserve order).

Answer 5

One big disadvantage of your first "JSON based" notation that comes to mind is that some frameworks will have problems with (de)serialization of this. For example the DataContractSerializer (C# .NET) will expect the fields id1 and id2 to be defined (hardcoded) in the class of your objects users. I'm not sure if this applies to some Java frameworks, too. Maybe the framework will you use can deserialze it as a HashMap instead.

Altogether I'd find the array notation much more intuitive to work with when it comes to iteration etc.

Answer 6

Both approaches have their pros and cons and depends on what is it that you are looking at.

The array approach is easy to serialize and is more 'framework' friendly (you can add beans to a list and serialize the list and you are done). This allows, for example, a web-container to return the response without requiring any customization. This is likely to be supported out-of-the-box by most frameworks.

On the other hand, the object based approach is more difficult to generate (in relative terms) but its easier to lookup given the key is known.

So for ease of implementation (by producer), go for the array based approach. For ease of use (consumed by clients) go for object based approach.