- Uses 6.0
use a local profile called 'pickles' api and message handler projects have a shell script that does the deployment
When creating the integration, the Route Details should be: ANY /{proxy+} (ID: 4chq3d7) pointing to the lambda
User, PK, SK
- For API Lambda
- For Message Handler lambda
- Xray
- AppConfig (https://us-east-2.console.aws.amazon.com/systems-manager/appconfig/home?region=us-east-2#)
- Lambda role
- Lambda function
- Api Gateway using Http2
- Integration using ANY/{proxy+}
- Created custom messaging bus called pickles-app-messagebus-dev
- Created event rule to route to the MessageHandler lambda
- See if we can wire in FluentValidation into the pipeline instead of explicitly calling it out.
- See if we can abstract the AppConfig (or the like) so we can use the provider pattern for configuration.
- Add a user to the system with a first name, a last name, an email and a phone number. After the user is created, they receive an email notifying them they were added.
- Update actions to change phone number, etc...
- Remove a user who no longer wants to participate. Again a notification would be sent
- Create a league with a name, location, start date and optional end date (assume all activities are PB for now with single scoring algorithm)
- Add an existing user to a league, thus creating a "player". A notification sent to the user notifying them they have been added as a player to a league.
- Remove an existing player from a league, thus preventing them from playing in it. All their previous activity would be saved for ranking and reporting purposes.
- Schedule a (pod) game with a date, location, list of players and who initiated. Notification goes out to all players with this information.
- Score a (pod) game, which can be previously schedule or unscheduled. Standard current pod scoring facts provided; player match up and final game scores. No need to summarize, the software knows how to add. Notificaiton would go out to all participants for review (and possible validation). At this point, no updates to a played pod should be necessary as the system will do the math and not get it wrong.
- (System event) When a game is scored, apply teh scored game to the current standings. Send out a notification to the participants with their new rankings.
- Get current standings (in some kind of format)
- Get historical standings (similar to what is sent out today)
- If a player has not played in a game during the last 7 (configureable of course) calendar days, their ranking decreases by 5 spots (or something like, like 10% of the total pool, which allows for smaller and larger leagues). A notification goes out to the player saying they violated rule #7.
- Users should have the ability to toggle all notfications that are generated by the system. We need to decide what the default set of notifications are. Note, this requires a interface for the user to
- User Created
- User Added to league
- User Removed from a league
- Game Scheduled
- Game Scored
- Standings updated for their game
- League standings updated
- Rule #7 violation applied