papajohns_notes.md

Papajohns Integration Notes

• The menu has “Store Fees” in it, i.e. delivery fees. Do we need to care about these?

• Looking at the createCart API, we will need to store more than just a single ID in items.

  For products:

  • baseProductId - the primary ID of the product (i.e. 107726)
  • code - the product code passed in the menu (i.e. TH:SP-3000)

  For modifiers:

  • code - the item code passed in the menu (i.e. SS)
  • modifiers do not have a baseProductId
  • While PJ's menus do not necessarily have "nested modifiers," we will store alterationQuantity (either WHOLE, LEFT_HALF, RIGHT_HALF) as a nested modifier. Example: Product (Philly Cheesesteak Papadia) --> Modifier Group (Toppings) --> Modifier Choice (Green Peppers) --> (Nested) Modifier Group (Choose Size) --> Modifier choice (Left Half). Our ordering system can then assume that any "nested" modifiers are actually an alterationQuantity record.

  Product IDs will be stored internally as the concatenated code and baseProductId (e.g. 107726,TH:SP-3000). Modifier choice IDs will just be the code, and nested modiifer IDs (restricted to alterations) will be the alteration code from the menu (WHOLE, LEFT_HALF, or RIGHT_HALF).

• The structure for various menu items is a bit confusing when looking at how different items are structured. If we look at different examples, it seems like they would need to be treated differently depending on the product. Take a pizza menuItem vs. a dessert menuItem (truncated for simplicity, the availableProducts list is actually much longer):

  Pizza Example:

   {
      "description": "BBQ Chicken Bacon",
      "productCategory": "PIZZA",
      "defaultDisplayProduct": {
        "name": "10 Inch Original BBQ Chicken Bacon Pizza - USA",
        "mdmId": "107794"
      },
      "availableProducts": [
        {
          "name": "10 Inch Original BBQ Chicken Bacon Pizza - USA",
          "mdmId": "107794"
        },
        {
          "name": "10 Inch Gluten Free BBQ Chicken Bacon Pizza - USA",
          "mdmId": "107810"
        },
        {
          "name": "12 Inch Original BBQ Chicken Bacon Pizza - USA",
          "mdmId": "107804"
        },
        {
          "name": "14 Inch Original BBQ Chicken Bacon Pizza - USA",
          "mdmId": "107796"
        },
        {
          "name": "14 Inch Thin BBQ Chicken Bacon Pizza - USA",
          "mdmId": "107798"
        },
        {
          "name": "16 Inch Original BBQ Chicken Bacon Pizza - USA",
          "mdmId": "107800"
        }
      ],
    }

  Desert Example:

  {
    "description": "Baked Dessert",
    "productCategory": "APPETIZER",
    "defaultDisplayProduct": {
      "name": "Cinnamon Pull Aparts",
      "mdmId": "108598"
    },
    "availableProducts": [
      {
        "name": "Cinnamon Pull Aparts",
        "mdmId": "108598"
      },
      {
        "name": "8 Inch Chocolate Chip Cookie",
        "mdmId": "108594"
      },
      {
        "name": "8 Inch Double Chocolate Chip Brownie",
        "mdmId": "108596"
      }
    ]
  }

  BBQ Chicken Pizza makes sense as its own top-level product on our menu, and the variations (10 Inch, Gluten Free, etc.) make sense as product modifiers. However, Baked Dessert would work very poorly as a top-level item; I may be specifically looking for Cinnamon Pull Aparts but not know they are even available until I drill down on the Baked Dessert product.

  Based on the createCart API, it seems like every item the availableProducts section of a menuItem is meant to be a top-level product on the menu. This is the easiest approach, although having every single size variation of every single pizza as a top-level product will make for a slightly cluttered menu (also, papajohns.com does not display it this way.) The alternative would be to implement custom behavior for any Pizza items. The downside with this approach is that the createCart API is very specific, so if we did turn products into modifiers, our ordering system would need some very hacky logic to convert order payloads to the expected state.