Array of objects vs Object of Objects
The issue is to decided the trade offs between 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 array of objects as it suits my requirements and better performance and 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 at the server. I am not able to decide on which notation should I use at the back end (which eventually will also affect the UI too).
Any thoughts/suggestion about performance, maintainability or scalability is appreciated.
It is a total opinion based question. There might be many other points, but I can point out as 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 client side, some how you will require the ids present in your JSON i.e. either hard coding it 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:
- 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.
- As pointed out by @JBNizet, 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 client side, so array based approach will not create any problem. And transforming array into map is possible on both the side (server and client) if you want id based approach.
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 desicion 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)
Along with all the above technical difference, I think there is a fundamental difference in the purpose and meaning of an Object and an Array.
- The properties of an object DESCRIBE/DEFINE the object whereas
-
The elements of an array does NOT DESCRIBE/DEFINE the array, on the contrary the array defines what it's contents are. Do note - I am not talking about technical aspects. You can have any combinations technically but semantically each has its purpose.
For example a card holder. Each card does NOT DESCRIBE/DEFINE the card-holder. But the card holder does define it's 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:
Each object which represents a person is defined by the properties id, firstName and lastName.
-
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 right manner.
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.
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).