For testing functions locally (or in CI), need to provide mock data (in the form of JSON files).

Create a JSON file for the following:

• getDrinksForBarLocation - cardiff
• getDrinksForBarLocation - newport
• getDrinksForAllLocations

Once done, could potentially run serverless invoke local during CI to verify they don't error.

Currently no Access-Control-Allow-Origin header is present. This stops the API being called from a webpage.

• Add header as: "Access-Control-Allow-Origin": "*"

Currently a bar location has to be entered for each session. This would be better to change and store the user's choice so we do not have to ask them (or require they provide it) each time.

This involves:

• Add DynamoDB resource the serverless.yml
• On setting a bar location, store it (lots of docs available on this)
• Possibly (probably) add in basic state machine for obtaining bar location, and moving on to available questions

Possible flows:

First time user

> Alexa, ask Tiny Rebel to suggest a drink

[check if user has provided bar location before]
[=no]

>> Should I check Cardiff or Newport?

> Cardiff

[store bar location as Cardiff]

>> You might like.... (etc.)

Returning user with set bar location

> Alexa, ask Tiny Rebel to suggest a drink

[check if user has provided bar location before]
[=yes]

>> You might like.... (etc.)

Returning user, overriding bar location in request

> Alexa, ask Tiny Rebel to suggest a drink in Newport

[check if user has provided bar location before]
[=yes (Cardiff)]

>> You might like.... (etc.)

etc.

Alexa SDK supports state flows and per-user attributes as would be required to implement this. See SDK docs.

Add support for getting a drink suggestion based on an upper limit, e.g.

Alexa, ask Tiny Rebel to suggest a beer that costs less than £4

This would involve:

• Create new intent with "UpperPriceLimit" slot
• Handle bar location as dialogue? Or add as custom slot, though seems that could get a bit wordy
• Parse upper price limit into number (slot type?), and filter out all drinks where drink.price >= slot.upperPriceLimit

Add support to suggest a drink based on type, e.g.

Alexa, ask Tiny Rebel to suggest an IPA
Alexa, ask Tiny Rebel to suggest a pale ale
Alexa, ask Tiny Rebel to suggest a cider

This involves:

• Adding new intent with DrinkType slot
• Handling bar location (either via dialogue, or via extra slot, though that could be too wordy)
• Filter drinks by drink type slot value. This is more complicated than drinks.dinkType === drinkTypeSlot as certain types overlap (e.g "IPA" should match "Pale Ale"). Need to think of best way of matching these.

Originally hacked together in JS to get something working and deployed.

Convert to TS and add build step prior to deployment.

• Refactor to TS
• Add dist folder to gitignore
• Add src folder to ignored deployment folder
• Run complilation prior to deployment
• Modify serverless.yml to point to compiled files

As this repo contains two services, i.e. JSON API and Alexa skill, calling it "tiny-rebel-api" no longer makes sense. "tiny-rebel-web-services" would be a better name.

• Change repo name
• Update README.md
• Re-encrypt secure Travis env vars once repo name has changed

• Add README for API
• Add README for Alexa skill (with sample utterances)
• Modify top level README to link to service READMEs

Currently using default memory allocation of 1GB. It seems requests are using about 25MB per request, so can potentially drop this by a lot.

Needs investigation.

• Is memory allocation per request? (Can a function instance handle multiple requests?)
• How much memory is used by each Lambda function?
• Does reducing memory allocation help with billing?

Use speech synthesis markup (https://developer.amazon.com/public/solutions/alexa/alexa-skills-kit/docs/speech-synthesis-markup-language-ssml-reference) to improve the realism of the speech output.

e.g.

• Emphasis on possible bar names when prompting for missing bar location
• Emphasis on beer name
• Try out marking up units (e.g. %ABV, quantity)

Need to try this against actual voice output instead of just testing the text response.