Issue #25 Question - 'Lookup SKU Codes'

[jayrevolinskyjr]

For #25 , what we would consider the extent of our ability to lookup common SKU codes? Would this be a feature where we only expect the user to type in the SKU code and then it spits out the product and/or nutrition information?

[AbhinavReddy-Dev]

More like using the camera from the web app to scan the item code, this can come in use for both the user and the admin?

[jayrevolinskyjr]

Right, could be useful to add items to local pantry database if used by admin and to checkout items from database if used by either an admin or user.

However, aren't we assuming that PantryNode is running in a web browser and not on an app? Phones can browse the web but an app would ensure ease-of-access and would likely require use of React-Native for the frontend.

[AbhinavReddy-Dev]

There are scanners that can help use the camera from the browser, like the one you suggested below.

[jayrevolinskyjr]

Quagga looks promising for barcode scanning, it's open-source and free. I am unsure if it works with LPU.

[ysiddhapura]

Quagga looks like a good library to use. After doing some more research it is compatible with multiple frontend frameworks.

[kbuffardi]

Sorry I hadn't noticed this discussion earlier.

Most items (e.g. cans) have UPC codes and there should be some resource for us to look up those codes. Produce usually has a PLU code and IFPS maintains a standardized list that associates each code with the food item it identifies. For both PLU and UPC, it would be ideal if we had a local representation for quick item lookup (e.g. table[s] in our database). If we don't have direct access to all of the common codes for both, we may entertain other options (e.g. using 3rd party libraries or an API, but let's aim for our own storage if possible. Let me know if you don't think that is possible/practical.

From a user's standpoint, I like the idea of integrating a code scanner in the front-end, but we should also integrate a way to manually enter a code (via keyboard) in case the user is having trouble getting the scanner to identify something.

[ysiddhapura]

We have added a way to manually enter the code with the scanner in the front-end.

[jayrevolinskyjr]

I think a local table for the most common bulk produce items is reasonable given that the PLU code list curated by the IFPS is mostly complete. However, I think handling edge cases is a huge problem since the local database is likely not to have all of the UPC codes. This could be remedied by integrating a library/API to handle edge cases, but then there is also the edge case where that library/API does not have the PLU or UPC code.

So, I think that we could use a Proxy to lazy-load the necessary functionality in order of precedence (given which of the three returns a result for the PLU/UPC codes): the local database, library/API, and 'Other' edge case.

The lazy-loading can avoid the computational overhead of cycling through all of the lookup options every time a PLU/UPC code is entered into the system since it will only load a given lookup option if it confirms that it has the PLU/UPC code.

I can work on the design if this seems reasonable.

[jayrevolinskyjr]

I have done further investigation and found that OpenFoodFacts is an Open-Source/Free API and Database that will allow us to make GET requests with a given barcode relatively easily with decent quality.

[kbuffardi]

It is worth noting that the newly proposed ER diagram does not account for different types of item codes (e.g. both UPC and PLU). However, we might have to have different types of items with different types of codes (perhaps even using one of the design patterns we've been studying).

[jayrevolinskyjr]

A Decorator sounds like a good option for this, the base value could be the same for each code and then the Decorator base class could track which type of code it inherited from.