Ans: The aim of nimn data format is to reduce the size of data. Processing the data or whether it can improve the performance depend on implementation. However as you have the data structure in advance, it's processing can be faster.
Ans: The size of Nimn data is smaller than compressed JSON.
Ans: You need to maintain the order of keys in schema. Fields in original data can be jumbled.
Ans. You'll have find the correct way to make it structured to use Nimn format.
Ans: Premitive data are just values. They don't have any object structure. Hence there is no benefit you'll get them if supported by Nimn format.
Ans: Yes. Nimn is basically about data format not the data.
Ans: Nimn in itself doesn't apply any security mechanism. You either can encrypt particular field's data or the whole data after parsing to Nimn format.
Q: I'm adding some fields in server response but I don't want to update client right now. Would it still work with 2 different schemas?
Ans. Yes. Don't change the order of fields defined in server response schema. Add the extra fields in last. In this case, client schema should automatically ignore extra fields.
Q: I have 2 different schemas at client side and server side which differ in terms of field's name and their values. Will it work?
Server
{
"name" : "string",
"dob" : "string",
"isRegistered" : "boolean",
}
Client
{
"dob" : "string",
"name" : "string",
"registered" : "boolean"
}
Ans: Above example will not give any error at the time of deserialization but you'll end up with unexpected result. Eg
Data to serialize
{
"name" : "Amit gupta",
"dob" : "some date",
"isRegistered" : true
}
Data after deserialization
{
"dob" : "Amit gupta",
"name" : "some date",
"registered" : true
}