Devin Castaban

We chose to use AWS Lambda to handle our client's HTTPS API Requests as it integrates seamlessly with the REST API provided by Amazon API Gateway. It is incredibly easy to link a REST API provided by API Gateway to an AWS Lambda function that does the required work within AWS, such as executing an SQL Query in our Amazon Aurora SQL database. AWS Lambda was the obvious choice to integrate our REST APIs with our SQL database.

We chose React for our website's frontend as React is the most prominent Javascript framework and our dev team has extensive experience with it. The AWS SDK integrates flawlessly with React and a member of our dev team has used the AWS SDK with React many times before, contributing further for our choice of using React over another Javascript framework, like Angular. A member of our dev team has also done state management with MobX in React before, giving us another reason to choose React as we expect we will need to keep track of some sort of global state within the React website.

Amazon Cognito allows us to easily manage user pools and authentication in our React frontend, ensuring that only authorized users can access the website and by extension our database. Easy addition of users and enabling of two factor authentication contributed to our reasoning to choose to use Amazon Cognito for our user pools.

We decided on using an SQL database since the data we'll be storing in our database lends itself easily to a relational database design. A relational database also appealed to us as we will be dealing with large volumes of data, requiring a performant database that can handle quick reads and regular writes, while guaranteeing consistent data integrity.

We chose Amazon CloudWatch to monitor all of our AWS microservices as it is automatically integrated with all microservices within AWS, being the default logger for every service. It is also very easy to alarm on any issues within any of our AWS microservices, such as a database experiencing more reads or writes than we might expect.

We chose to use Amazon Route 53 since it provides very easy managing of DNS records that we will need to add in order to host a website through Amazon CloudFront at a CNAME of our choosing. Route 53 leads you through a quick one time addition of DNS records for your CNAME and after that you never need to touch it again, which made it very attractive for us to use it store our DNS records for our website's CNAME.

We chose Amazon CloudFront to host our website as it makes hosting a website extremely easy to do. Setting up the CNAME that we will chose to host the website on for this project will be quite easy with CloudFront, as it gives precise direction on what DNS records to add to Amazon Route 53, among other CNAME setup steps.

We chose to use Amazon S3 to store the build of our React website as uploading the build that npm generates of our React website to an Amazon S3 website is seamless using the AWS CLI. Amazon S3 also provides primitive website hosting features for fast viewing of a developer version of our website, which contributed to our reasoning to use S3 to store the build of our React site as it will enable us to store the website build while also providing a dev website that won't be visible to customers immediately.

We chose to use ES6 for our React website's Javascript since ES6 brings with it support for so many features that can be oh so useful when writing a complex website. Since ES6 is the modern standard nowadays, there was no reason for us not to use ES6, as without it we would be depriving ourselves of useful features for no benefit.

We chose to use HTML5 for our React website as HTML5 is the newest, mainstream version of HTML and it supports many things that used to require outside libraries to accomplish, such as canvas. We may need to use some features specific to HTML5 in constructing charts, especially any chart libraries we may import, so it was a no brainer to use HTML5 as it is the modern standard for HTML.