Caching confusion

[Patrick Chasco]

Many of the API methods specifically indicate fields that may be stored. For example, food_id and serving_id. I find this confusing because it would not really be possible to implement an intuitive food log without storing additional nutrition information and at the very least, the name of the food. Not to do so would mean that this data is these are being repeatedly fetched in real time when the user navigates the application, and also would make the application nearly unusable offline.

I see there are several conversations in the group that indicate Fatsecret allows for storage of some data on the local device. Is this still true? And if so, does this extend to backups of their data stored online? My application syncs their individual food log to the cloud associated with their user account. This is not usable as a substitute for Fatsecret's API in any way, but a narrow reading of the Fatsecret guidelines and API documentation seem to preclude this usage. If this is not allowed, then I will need to fetch this data as it is pulled to the local device during sync, which might cause their historical data to become inaccurate if a product's nutrients or descriptions change later.

Before I commit to using Fatsecret, can I confirm that I am allowed to store the following data elements on the user's local device, and also store it in a database in the cloud associated with that user's user account, not accessible to any other users' accounts?

* Food id

* Food name

* Brand name

* Serving id

* Serving description

* Calories

* Protein

* Fat

* Carbohydrate

* Food image URL

Thank you

[seba...@fatsecret.com]

Thanks Patrick.

You can cache/store the data on a user's device i.e. inside the application (but not in your backend).

That said 95% of our API developers simply store the foodID and ping the API in real time given there are no API call limits and there is minimal latency

[Patrick Chasco]

Thank you  For your response. Unfortunately, this is an existing app and retrofitting that functionality into. It will be complicated and I am not sure it will be worth the effort. Have a nice day.

--
You received this message because you are subscribed to the Google Groups "fatsecret Platform API" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fatsecret-platfor...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/fatsecret-platform-api/4f5ca572-d498-4b55-a585-186f255c74acn%40googlegroups.com.

[Patrick Chasco]

I am still trying to decide whether I should implement Fatsecret in my application. Do food items ever change on your system? Or if there is ever any change, is a new food created with a new id? One issue I see with the solution proposed is that at the very least I need to retain the pertinent nutrition values because if they change, then when I fetch the data from the Fatsecret API the values could be different than what they were when they originally created the entry.

[seba...@fatsecret.com]

Thanks Patrick for following up. New foods will be created with a new foodID (which is vast majority of the 1,500 changes we perform every day). There are a small number of branded/restaurant foods that receive updates based on their brand owners/manufacturers