rjriel / rhok-bad-date-serverless

Bad Date App - Backend

This is the code for the supporting (serverless) functions for Bad Date App created for the Random Hacks of Kindness RHoK #8 Hackathon.

Use Case

The application has two actors (actors: humans who interact to a system): End users, and moderators

• End users
  • Create accounts
  • Create reports
  • View their own reports in full
  • Edit their own reports
  • View select portions of reports that are approved by moderators
  • Contact organization of the moderators through the application based on their reports
• Moderators
  • Create curated or modified versions of full reports from end users which are presented to the public
  • Correspond with end users regarding reports

Components

The components of the system are as follows:

• Static web page stored in a companion repository https://github.com/rjriel/rhok-bad-date-serverless
  • The web application deploys as a static page to an Amazon S3 bucket
• Amazon API Gateway using schema in swagger.json
• Lambda functions in /src, where each function is an app.py file in its folder
• DynamoDB database (which are accessed by the aforementioned Lambda functions)

rhok-bad-date-serverless's Issues

Deployment to a new AWS account should be automated

The deployment of the "Bad Date App" should be automated for building, and deploying to an AWS account.

DynamonDB ttl takes too long to come into effect

The dynamoDB can take upto 48 hours to excise the table. Currently a work around exists to validate the session token's life in the authorizer. DynamoDB features should be monitored for when the db ttl feature becomes usable, or a new db solution should be found.

Deployment instructions need to be documented

Details on how to deploy the bad date app API should be documented.

Continuous integration prototype

Add a subsystem to automatically check code when it is pushed to Github. Hopefully the system will have these attributes as well:

• Run completely using Amazon AWS Lambda or other function so we don't need to have a dev/test server all the time
• A dev can work on a development branch and call the integration tests at will on their dev branch (so they don't need to mess up Master to be able to run tests)
• Mark any issues on the Github commit as a passing or failed build, with logs (similar to a Jenkins multi-branch pipeline)

Penetration Testing / Service Hardening

A security audit needs to be ran for penetration testing and then hardening performed for any vulnerabilities found.

Moderator users should be able to managed via API by other moderators

Currently moderators are added / removed /updated via manual intervention in the DynamoDB. Moderators should be able to add or remove other moderators from the app (or a seperate admin app) via an API.

Lambdas should take configuration from environment

currently hard coded values are used for a lot of configuration in all the Lambda fns, these should reference the envvars for their values.