As a dev, I want to be able to retrieve a list of labels with some infos about each labels.

[Youllou]

Description

Context We want to display a list of labels to the user on the frontend

Problem Statement At the moment there is no way to know what are the saved labels in the database unless you already know their ids. It would be nice to have a route to ask for the labels kth-nth with some informations about them. The required informations would be :

• Label ID
• Company name
• Fertiliser Name
• Registred No
• Lot Number
• User
• Upload Date

Acceptance Criteria [Provide clear criteria for what needs to be done to
solve the problem and close the issue. This helps developers understand the
desired outcome.]

• [ ] A route is available to get a list of labels
• [ ] The route asks for which elements you want to retrieve (would be a kth element to nth element)
• [ ] The route answers with a list of n-k labels
• [ ] Each labels contains the elements previously written

Additional Information see ai-cfia/fertiscan-frontend#176

[snakedye]

I propose a /search endpoint that'll take a JSON like this:

{
    "label_id": "",
    "user_id": "",
    ...
}

The keys are still uncertain.

This could avoid some API breakages because adding another option would just be to accept another key in the JSON.

[SamuelPelletierEvraire]

Can we have a /search and a /retrieveAll that return all the saved labels? retrieveAll(startIndex, endIndex) startIndex: from occurrence X endIndex: to occurrence Y Example: retrieveAll(10, 20) This will return all the saved labels specified between the 10th and 20th occurrences.

This would help ensure the waiting time on the frontend is not too long for the user.

[snakedye]

I was thinking about just using GET /form. A search route would make the get form redundant. I don't think we need a retrieve all since GET /form would cover that use case. It would just be a matter of making the right search query.

This will return all the saved labels specified between the 10th and 20th occurrences.

I don't understand this use case and why it would be necessary.

[SamuelPelletierEvraire]

It would be necessary in the case that we have 1000 saved labels and if we retrieve them all that could make some latency for the user before all the label is upload to the app

[snakedye]

@SamuelPelletierEvraire That would fall under the scope of the search query. Instead of just asking the backend the dump a N amount of random labels, I'm proposing to a proper search query.

In that query you could choose to look for the labels of the user and it's unlikely that he would have thousands and even if he had thousands you could filter that in the query.

[Francois-Werbrouck]

I'm going to put a soft stop on this issue. I think we need to go back to the drawing board and decide how we want to handle the search and what needs it will cover, instead of going ahead and start developing right away.

The following is true:

[...] in the case that we have 1000 saved labels and if we retrieve them all that could make some latency for the user before all the label is upload to the app [...]

But having this:

startIndex: from occurrence X endIndex: to occurrence Y

Is not the solution and doesn't make sense. (I know it is for the concept of having pages but it aint it imo)

Why would the user need to see ALL the labels at once? Shouldn't we restrict what we display at first and then depending on a few filters showcase some data?

We can also fetch everything and only have the ids and name. Once the user chose which fertilizer or company they want from a list, then we could load all of that company fertilizers or all the label of the selected fertilizer.

I think our current approach to the solution is too much based on what the client says they need. We have the task of building a good solution over multiple iteration and jumping in without planning the scope of what we are implementing is not such a great idea in the long run. It makes the devs constantly work on their code which become exponentially more costly over time (like @k-allagbe once told me 😉)

I dont want to sound like I'm bashing you guys work. However, I think we need to look farther in the future while planning this issue since alot of architectural decision will be based on it for all layers of this project.