How to handle resource and need Items - Typing and information structure

[mehmetkuzu]

Issue Description

The backend team ran into an issue.
This issue is related to the information design of our resource and need items. Actually it is not a big problem, or even a problem but we need to make a decision about how wi will handle both the data entry and the data itself.

I prepared a video (with shared screens) to reveal the scope of the subject.

You may think that I am proposing a structure here. But actually not. A solution should be more elaborated. But take this as a starting sign for the discussion.

video1907410125_1.mp4

video1907410125_2.mp4

video1907410125_3.mp4

Deadline of the Issue

22.10.2023

Reviewer

Begüm Arslan

[rburaksaritas]

We discussed that the following structure is a convenient way, specifying subtype as field, then details in a subsection.

{
    "_id": ObjectId("unique_id_for_resource"),
    "condition": "EnumValue", 
    "initialQuantity": 100,
    "currentQuantity": 95,   
    "subtype": "SpecificResourceType",      // "Cloth", "Food", ...
    "details": {  
        "size": "M",
        "gender": "Unisex",
        "age": "Adult",
        "subtype": "Shirt"
    }
}

We then can add a validation mechanism, like creating a template for all possible request bodies that will come to backend. Example template for one resource or need type:

{
    "_id": ObjectId("unique_id_for_template"),
    "type": "Clothes",
    "for": "Resource", // or "Need"
    "attributes": [
        {
            "name": "size",
            "dataType": "String",
            "possibleValues": ["S", "M", "L", "XL"]
        },
        {
            "name": "gender",
            "dataType": "String",
            "possibleValues": ["Male", "Female", "Unisex"]
        },
        {
            "name": "age",
            "dataType": "String",
            "possibleValues": ["Child", "Adult", "Senior"]
        },
        {
            "name": "subtype",
            "dataType": "String",
            "possibleValues": ["Shirt", "Pants", "Shoes"]
        }
    ]
}

As backend team we thought that this might help frontend team for displaying possible fields of a resource or need to be submitted. We then can validate an incoming request body with this template as well.

Please provide feedback.

[mehmetkuzu]

We discussed that the following structure is a convenient way, specifying subtype as field, then details in a subsection.

{
    "_id": ObjectId("unique_id_for_resource"),
    "condition": "EnumValue", 
    "initialQuantity": 100,
    "currentQuantity": 95,   
    "subtype": "SpecificResourceType",      // "Cloth", "Food", ...
    "details": {  
        "size": "M",
        "gender": "Unisex",
        "age": "Adult",
        "subtype": "Shirt"
    }
}

We then can add a validation mechanism, like creating a template for all possible request bodies that will come to backend. Example template for one resource or need type:

{
    "_id": ObjectId("unique_id_for_template"),
    "type": "Clothes",
    "for": "Resource", // or "Need"
    "attributes": [
        {
            "name": "size",
            "dataType": "String",
            "possibleValues": ["S", "M", "L", "XL"]
        },
        {
            "name": "gender",
            "dataType": "String",
            "possibleValues": ["Male", "Female", "Unisex"]
        },
        {
            "name": "age",
            "dataType": "String",
            "possibleValues": ["Child", "Adult", "Senior"]
        },
        {
            "name": "subtype",
            "dataType": "String",
            "possibleValues": ["Shirt", "Pants", "Shoes"]
        }
    ]
}

As backend team we thought that this might help frontend team for displaying possible fields of a resource or need to be submitted. We then can validate an incoming request body with this template as well.

Please provide feedback.

I thing this is a very convenient way to solve the problem.

• The UI side gets the field names and even the possible items (for any listbox) directly making API calss.
• As our data transfers all include JSON standard (even our database layer is collection based - with high JSON compatibility) all will go well and easy.

I strongly support Burak's proposed solution.

[rburaksaritas]

we are currently implementing the backend models in format

{
    "_id": ObjectId("unique_id_for_resource"),
    "condition": "EnumValue", 
    "initialQuantity": 100,
    "currentQuantity": 95,   
    "type": "SpecificResourceType",      // "Cloth", "Food", ...
    "details": {        // predefined subtype details
        "size": "M",
        "gender": "Unisex",
        "age": "Adult",
        ...   
        }
}

Closing the issue for now, this matter can be revisited in the future if unconvenience occurs.