Definition of Model Layer

[eexe1]

Defines what models the products should have. & How the model layer interact with the other layers.

[eexe1]

@ScrimpyCat do you think of anything that might affect the data structure within the App? Since the models should be transformed from/to the backend.

[ScrimpyCat]

Not really. For most part it should be fine (may just need to add an additional field here or there), since you'll be able to have control over what data you want from the backend (as the API is using GraphQL).

[ScrimpyCat]

I'll add here the data layout of some of the current services though. So you know what to expect from those/can also let me know if there's something you think is missing. Just making dinner at the moment, but will do it in a bit.

[ScrimpyCat]

Haven't implemented a service for products yet, but from the old backend the API exposed these fields:

object :food do
    field :id, :id, description: "The id of the food"
    field :name, :string, description: "The name of the food"
    field :description, :string, description: "The description of the food"
    field :cuisine, :cuisine, description: "The type of cuisine the food is"
    field :diets, list_of(:diet), description: "The diets that are allowed to consume this food"
    field :allergens, list_of(:allergen), description: "The allergens this food effects"
    field :ingredients, list_of(:ingredient), description: "The ingredients in the food" #todo: support addons later
    field :prep_time, :integer, description: "The preparation time of the food"
    field :available, :boolean, description: "Whether the food is available or not"
    field :calories, :integer, description: "The caloric amount of the food"
    field :price, :price, description: "The price of the food"
    field :image, :string, description: "The image source for the food"
end

Probably biggest differences will be calories will be contained in a nutrition field (which you could either retrieve just the calories or other details), a rating field (will be a normalized number 0.0 - 1.0; so you can choose to represent it however you want), addons (which will have their own prices attached), possibly a discount (which may be amount reduced by, and possibly a description; this is if we add support for the dynamic pricing. however actual price will always remain the price field as that will include the discount applied), attributes (hot, cold, spiciness, etc.), portion size, ordering availability (delivery, eat-in only, etc.), etc. There's some other stuff but that's not really relevant to the user app, if you have ideas for other fields (either things you'd like or stuff you see is just missing) let me know.

As for all products I'm likely going to make it a polymorphic type, so you'll be able to match the fields you want from each differing type in your query to the API. While I haven't thought about the details too much I'd imagine we'd have some accessory type (for drinks or other items), and combo type (reference other items it includes).

As for the data types for the fields, for the most part they'll be strings unless it's intended for the client to manipulate them (then they'll be numeric types). For complex objects, I'll usually have a field that can be used to get the "presentable" string for it.

[eexe1]

Nice! I will implement first based on the old data structure then add the changes you described. I will post a detail structure here later on.

[ScrimpyCat]

Ok 😄

The old types related to food can be seen here:

https://github.com/ZURASTA/bonbon/blob/master/web/api/schema/item/food.ex#L12-L25 https://github.com/ZURASTA/bonbon/blob/master/web/api/schema/cuisine.ex#L8-L12 https://github.com/ZURASTA/bonbon/blob/master/web/api/schema/cuisine/region.ex#L7-L14 https://github.com/ZURASTA/bonbon/blob/master/web/api/schema/diet.ex#L7-L10 https://github.com/ZURASTA/bonbon/blob/master/web/api/schema/allergen.ex#L7-L10 https://github.com/ZURASTA/bonbon/blob/master/web/api/schema/ingredient.ex#L7-L11 https://github.com/ZURASTA/bonbon/blob/master/web/api/schema/price.ex#L6-L10

You won't need all those fields from those objects, so anything you don't need, don't include in your model (you tell the API what fields from what objects you specifically want).