The application needs a user interface to allow users to register, login, and manage their subscriptions. Plan on using React. Add a UI testing framework like Cypress or Playwright.
The web application also needs to have a public page that provides a clear and comprehensive overview of the campaign's objectives and interactions the end-user would experience after opting in. For more details about the Campaign Approval Best Practices, see here.
The user interface should be a Progressive Web Application (PWA) that can be installed on a user's device.
The user interface could provide a billing report for the user.
Segregate the user interface from the API to allow for independent scaling.
More performance tests should be added to the application to identify bottlenecks.
The application could maintain a list of subscribers to notify for each vendor rather than querying for subscribed users in the user collection.
- Save an array of subscribed phone numbers to the vendor in the Notifications collection.
- Emit an event to notify the Notification class to add a subscriber.
- Fetch subscribers from the Notification collection when it is time to send a message.
- Add a utility for synchronizing the list of phone numbers subscibed to the vendor with the source of truth User collection as a fallback in case of failures.
The application has been instrumented with Application Insights, but custom telemetry data could be added to provide more insights into the application's performance.
- Evaluate how to capture application metrics like Node performace.
- Consider OpenTelemetry for distributed tracing.
Bungie's API is a external dependency that could be unreliable. Implement a circuit breaker to prevent the application from making requests to the API when it is down. Check out Opossum for a Node.js circuit breaker.
Add a timer to automatically refresh the manifest file when Bungie releases a new version.
The application could be enhanced to use RCS to provide a richer experience for users. RCS is a messaging protocol that allows for more interactive messaging experiences. For example, a user could receive a message with a carousel of images of the players in a fireteam. See How to send an RCS message with Twilio and Node.js for more information.
Messages are saved to the database based on the Twilio data schema captured by the service through the web hook. When a user sends a message to the service, in converse with receiving a message from the service, the phone number the message is directed to, and identified in the data, is the Twilio messaging service's, not the user's. Therefore, the service cannot determine how many messages a user has sent to the service. The service can only determine how many messages the user has received from the service. This is a challenge because the service needs to bill users based on both the number of messages they send to the service and the number of messages received from the service.
I'd like to explore the possibility of using AI to drive a feature that uses text recognition from an image to determine players in a fireteam. A user could send a screenshot of the players in the lobby before the start of a match and receive a report from the service with the players' stats in order to highlight strong players over weak ones.
Twilio supports a verification link that can be sent to a user's phone number to verify their identity. This could be used to verify a user at sign in instead of sending a magic number to the user's phone. See Twilio Verify for more information or How to send an SMS magic link for one-click phone verification for an example of how to implement this feature.