Road Map

[alvyn279]

• Infra:
  • Containerize Java application
  • Create ApplicationLoadBalancedEc2Service
  • Switch to public ECR repository
  • Set table name in CDK (maybe env var ?)
  • IMPORTANT: Check why health checks fail so often with task definition
  • IMPORTANT: Downgrade infrastructure to normal EC2 task without the load balancer and health
  • Why do some commands do not go through ?
    • Set up logs for container execution
  • Add log stream to container execution
  • NAT Gateway spendings (almost 2$ a day)
    • Documentation[1][2] We only need one public subnet that contains our single instance. Our route tables point to vpc endpoints for ddb interaction.
      
    • VPC endpoints to DDB
    • Internet Gateway for Discord API WebSocket
  • Segregate infra into test DDB and prod DDB tables
  • Hot reload with docker-compose volumes
  • DDB index on messageId ?
  • Restart container on failure
  • Look into SSM for secrets
  • GitHub Action to build/deploy/update ECS service (see if this is necessary)
  • Health check server
  • Dockerize CDK
• Bot:
  • Fix async issue on ping and create
  • Support multiple servers for DDB by adding guildId as attribute (redesign DDB)
  • List events
    • list upcoming
    • list between range
    • list on date
    • add created by in title of list item
  • Error handling (oops message)
  • Extract CommandReaction into a class other than DiscordEventsBot
  • Help command (sample usage)
  • Manage personal events
    • view my-events
    • return message id for delete
    • change title of bot response to have username of creator
    • Send PM for my-events instead of in public channel
  • Delete event
    • Delete multiple inline
  • Describing events with reactions
  • optional descriptions
  • Reminder messages
    • simple reminder
    • status command that tells which text channel is subscribed to the reminders
    • Make notifying delay configurable
    • current implementation won't work for reminding multiple servers !!
    • Support distributed systems arch
      Right now the singleton pattern for the scheduler only allows there to be a single instance servicing the bot at all times.
      Look into https://github.com/Discord4J/connect
  • Empty events message
  • Refactor ListDiscordEventsCommandArgs into more specific classes for each ddb repo op
  • Attendees
    • choose best way to store this info
    • string set must not be empty at write time
    • write repo functions
    • !attend-event + emoji reactions
    • Single-liner should be changed to show each event
    • remove reaction
    • mentions
    • add to every list function
    • help, readme
  • Important: Support more than one timezones (setting it manually)
  • Cache guild members fetch
  • Pluggable into any other Discord4J bot
  • Google Calendar and others
• Documentation:
  • Screenshots in README
• Tools:
  • linter for cdk

Takeaways

1. For single-task services, setting the desired tasks count matters at creation and at deploy time
   Solution: Set to 0 before update as per docs.
   Better solution: USE DAEMON MODE !!
   Preserve current desired counts on deploy of auto scaled resources aws/aws-cdk#5215
   fix(aws-ecs): update desired count to be optional aws/aws-cdk#12223
   (ecs): Optional DesiredCount value should be omitted in templates aws/aws-cdk#11951
2. NAT Gateway for persistent connections will eat your wallet.

[Stochastic-Adventure]

Hi!

This is a wonderful repo as I am looking to build a similar bot with AWS ECS as well.

Just curious what is the cost after removing the NAT Gateway?

Thanks in advance!

[alvyn279]

Hey @Stochastic-Adventure ,

I recall being charged around 2$/day solely for bot heartbeat (every 1-2 mins) traffic going through the NAT Gateway.

I think running continuously a single image of the bot cost around 8-10$ a month or so.

[Stochastic-Adventure]

Thanks!

$8-10 / month is reasonable.

One more question: did you use AWS Secrets Manager to store bot token?

[alvyn279]

Thanks!

$8-10 / month is reasonable.

One more question: did you use AWS Secrets Manager to store bot token?

Nope, I have it as an env var, but modifying the bot to make use of SM would probably be best practice here. Might be cheap too.

This being said, the current bot setup I have makes it quite hard to attack the secret as env var on the containerized app. The ec2 instance has no public IP, being in its own VPC, and what not.