Gourmet 2.0 Web Based Version Brainstorm

Gourmet Web-Based Plan:

HIGH LEVEL PLAN

At a high level, we distribute Gourmet in the following way:

• Front-end is HTML5/JS-based hybrid development for distribution to web + mobile + desktop app.

• Backend supports storing information "in the cloud" (on a server). An ideal backend might grow quite flexible, supporting offline and online storage, for example, or both private and public recipes. Ideally moving the backend to the cloud would allow us to aggregate user data in a way that could make Gourmet smarter about, for example, recognizing ingredients for combination in shopping lists or for calculating nutritional information. That said, our commitment to freedom means that users would be able to run their own server if they prefer and still have a fully functioning Gourmet.

• Importing recipes smoothly will almost certainly need help from a browser extension (or possibly bookmarklet) that lets users parse recipes on the page and send them to Gourmet. Recipe import is a prime area for collaboration and would need to be extensible and allow users to submit "recipes" for data scraping.

Funding/Open Source/How do you do open-source web apps?

• Code is open source, built with a plugin architecture to encourage expanding feature sets and collaborative hacking

• Shared server is subscription-supported or ad-supported. Data is always available for download in interoperable format (this is my non-negotiable: you need to own your data at the end of the day). You can run your own server if you want to and run all the code on your own, but I would have to maintain official versions in various app-stores, extension registries, etc.

• Users can share data w/ each other which will build a crowdsourced database for more efficient looking up of ingredient keys, parsing of webpages, etc.

Backend Plan Let’s think through the interface the backend has to expose…​

RecipeImporter - importUrl - importFile - importRecipe

RecipeDatabase - searchRecipes(q) - getRecipe(id) - importRecipe(url) - getImage(image-id) - getShortRec* (id)

(*I think we will likely want to make a lower-data version of getRecipe available that would omit all the starred attributes below and be useful for things like listing search results etc.)

     Recipe {
       title : '',
       source : {
 	 url : '',
 	 name : '',
 	 details : HTMLBlob,
       },
       preptime : Time,
       cooktime : Time,
       totaltime : Time,
       notes* : {
 	 'head':HTMLBlob,
 	 'foot':HTMLBlob,
       },
       thumb : source-url (or CDATA),
       image* : source-url (or CDATA),
       steps* : [
  	 {label:'',content:HTMLBlob},
 	 {label:'',content:HTMLBlob},
 	 {label:'',content:HTMLBlob},
       ],
       ingredients* : [Ingredient, Ingredient, ...]
     }

IngredientDatabase

• getIngredients(recipe-id)

• lookupKey (ing item)

    Ingredient {
       amount : NUMBER,
       unit : '',
       item : '',
       prep : '',
       ingkey : '',
       grams : undefined, // if we have density information
       recipeId : null, // for recipes as ingredients
    }

And our first, prototypical plugin is the nutritional plugin, which will add…​ To the backend…​ - getNutrients (ing key) - guessNutrients (ing item) - associateNutrients (ing, nutritionalKey)

To the frontend…​ - NutritionalInfoView

    NutLink {
      ingkey : '',
      nutkey : '',
    }

    NutInfo {
      nutkey : '',
      kcal : {amt:127,unit:'calorie'},
      satfat : {amt:3.4,unit:'g'},
      ...
    }