Some work exists to let recipes and ingredients have similar nutrition data stored, so that they can be referred to interchangeably. While it's possibly a separate issue to merge recipes and ingredients into just a single 'food' class, even if they are or aren't, it would help the flexibility of the system if the API could describe what nutritional value types are available. For example saturated fat is 'part of' fat content typically for a given food, as would unsaturated fat if it were added. For vegans/vegetarians/body builders tracking protein by itself is insufficient, as you would want to track the various amino acids if they were available to ensure you were getting complete proteins. If these were added to the backend, the front end would need work for every new nutritional value type that got added.
If instead the API could describe the nutritional value types, then the front end could dynamically create inputs based on the nutritional description.
Additionally, the server needs unit standardization. It may be more user friendly to display sodium in milligrams instead of grams, but its harder to maintain if the server stores that in milligrams instead of grams like all other nutrients. If the front end is up to par, then the server can simply store and work in simple units such as grams, UTC time, etc. The front end can convert grams, UTC, etc to a more user friendly unit/timezone when displaying and converting back to the basic server unit for a value before calling the api to store/update. This would allow more code reuse in the backend, and more freedom in the front end. For example I could integrate with a service that converts grams for certain known ingredients to cups/ml/volume measurements, and display a recipe in weight or volume as the user desires.
Some work exists to let recipes and ingredients have similar nutrition data stored, so that they can be referred to interchangeably. While it's possibly a separate issue to merge recipes and ingredients into just a single 'food' class, even if they are or aren't, it would help the flexibility of the system if the API could describe what nutritional value types are available. For example saturated fat is 'part of' fat content typically for a given food, as would unsaturated fat if it were added. For vegans/vegetarians/body builders tracking protein by itself is insufficient, as you would want to track the various amino acids if they were available to ensure you were getting complete proteins. If these were added to the backend, the front end would need work for every new nutritional value type that got added.
If instead the API could describe the nutritional value types, then the front end could dynamically create inputs based on the nutritional description.
Additionally, the server needs unit standardization. It may be more user friendly to display sodium in milligrams instead of grams, but its harder to maintain if the server stores that in milligrams instead of grams like all other nutrients. If the front end is up to par, then the server can simply store and work in simple units such as grams, UTC time, etc. The front end can convert grams, UTC, etc to a more user friendly unit/timezone when displaying and converting back to the basic server unit for a value before calling the api to store/update. This would allow more code reuse in the backend, and more freedom in the front end. For example I could integrate with a service that converts grams for certain known ingredients to cups/ml/volume measurements, and display a recipe in weight or volume as the user desires.