• Great to see you using TS! One issue: npm WARN deprecated [email protected]: TSLint has been deprecated in favor of ESLint. Please see palantir/tslint#4534 for more ***rmation. You should migrate

• You shouldn't need to do this in your Fragment class, it should happen in the auth middleware (I gave you code to do it in the weekly hints) https://github.com/shawnyu5/fragments/blob/master/src/model/fragments.ts#L14

• Use Buffer for your type on the data https://github.com/shawnyu5/fragments/blob/master/src/model/fragments.ts#L119

• Because you update these, you need to re-.save() the fragment too https://github.com/shawnyu5/fragments/blob/master/src/model/fragments.ts#L128-L129

• You can use Request, Response, etc. from the Express.js types for these https://github.com/shawnyu5/fragments/blob/master/src/routes/api/post.ts#L8

• https://github.com/shawnyu5/fragments/blob/master/src/routes/api/post.ts#L11 is wrong. This should already be parsed by the passport middleware, and available via req.user

• https://github.com/shawnyu5/fragments/blob/master/src/routes/api/post.ts#L13-L14 can throw, and anything that can throw, will eventually throw. You need try/catch

• Why do this, when you already have a reference to the fragment from above? https://github.com/shawnyu5/fragments/blob/master/src/routes/api/post.ts#L16

• Instead of this https://github.com/shawnyu5/fragments/blob/master/src/routes/api/post.ts#L18 do: res.json({...})

• Same issue here: use req.user https://github.com/shawnyu5/fragments/blob/master/src/routes/api/get.ts#L7

• fragment vs. fragments (only one when you get by id) https://github.com/shawnyu5/fragments/blob/master/src/routes/api/get.ts#L22-L24 Also, error handling

API Server Checklist

• Dockerfile and .dockerignore added to fragments GitHub repo
• Dockerfile employs Docker best practices for creating Docker Images
• Dockerfile uses a multi-stage Docker Build produces, producing the smallest possible production Docker Image of your fragments node server
• fragments Docker image is hosted as a public repository at Docker Hub under your account
• Docker Hub account secrets properly stored in GitHub repo
• fragments Docker image automatically built and pushed to Docker Hub on every new commit to the main branch via GitHub Actions CI workflow
• POST /fragments can now create any text/* or application/json fragments (i.e., you don't need to support images until Assignment 3), with unit tests. See 4.3.
• GET /fragments?expand=1 now returns expanded fragment metadata for an authenticated user. See 4.4.1.
• GET /fragments/:id returns an existing fragment's data with the expected Content-Type, with unit tests. See 4.5.
• GET /fragments/:id/info returns an existing fragment's metadata, with unit tests. See 4.7.
• GET /fragments/:id.ext returns an existing fragment's data converted to a supported type. Initial, you only need to support Markdown fragments (.md) converted to HTML (.html) using markdown-it (i.e., you don't have to do other conversions until Assignment 3)
• Unit test coverage should be at 80% or above, targeting all expected source files
• fragments Docker container is running manually on EC2 using pre-built Docker Hub image (i.e., without building manually on EC2)

Front-End Web Testing UI Checklist

NOTE: your web UI does not need to be polished or pretty, but must be functional, even if only in a very basic way. Remember, this is only for manual testing.

• Dockerfile and .dockerignore added to fragments-ui GitHub repo
• Dockerfile employs Docker best practices for creating Docker Images
• Dockerfile uses a multi-stage Docker Build produces the smallest possible production Docker Image
• Final layer uses nginx to serve the final static web site vs. node.js
• fragments-ui Docker image hosted as a public repository at Docker Hub under your account. NOTE: you don't need to automate this, pushing it manually is fine (you're obviously welcome to automate it if you want to).
• Basic support for users to create a new fragment, specifying the type of the fragment (e.g., drop-down or textbox). Any text (text/*) or JSON application/json fragment type should work. You could have the user type the fragment's content into a simple textbox, or support drag-and-drop, or use some of the many browser file APIs. It's up to you, but there needs to be some way to accomplish this. NOTE: this doesn't need to be fancy or highly polished; this is only for manual testing.
• Ability to get a list of the authenticated user's existing fragments with all metadata after successful login (e.g., you could print it to the console or dynamically generate UI elements like a table or list). It's up to you what you do, but there needs to be some way to accomplish this.

Submission

Create a technical summary report document (e.g., Word or PDF) and submit it to Blackboard. This document will discuss and demonstrate your progress to date on implementing the fragments service.

In your report, include all of the following sections and items. Make sure that any screenshots are properly explained with words as well:

1. A brief introduction that describes the update to the system since Assignment 1
2. Links to both Private GitHub Repos with all necessary files included in git
3. Links to both your public Docker Hub repositories with your built Docker Images
4. Link to a successful GitHub Actions CI workflow running your unit tests
5. Screenshots of your fragments API server running as a container on EC2 based on your Docker Hub image (i.e., shows health check JSON response in the browser or via curl)
6. Screenshots of your fragments-ui web app running on localhost and connecting to your Docker Container running on EC2 and your Amazon Cognito User Pool, doing the following:
   1. User authenticating with Cognito Hosted UI and showing the metadata for all of their existing fragments
   2. User creating a new JSON fragment
   3. User creating a new Markdown fragment
   4. Make sure at least one of the screenshots shows the Location header being set and returned correctly
7. Screenshot of running npm run coverage to show that you've been able to properly cover the majority of your files and lines of code. Make sure your coverage rate is high enough to reflect proper testing for all units of code (>80% and includes all source files in this release).
8. A brief conclusion, including notes about any bugs or issues that you still need to address in the final release.

Assignment 3

Please make sure that all of the following items have been successfully completed, based on the Fragments Microservice Specification.

API Server Checklist

• Docker Compose setup to run fragments, DynamoDB Local, and S3 LocalStack containers together in development and GitHub Actions CI workflow for integration testing
• Integration tests using Hurl and docker-compose properly set-up with scripts to easily run them
• Integration test cases cover all major aspects of the Fragments HTTP API Specification (i.e., all routes, success and error cases) using HTTP Basic Auth (i.e., testing with Amazon Cognito not necessary)
• Unit tests and Integration tests run on every commit to main branch via GitHub Actions CI workflow
• Fragments Metadata stored in Amazon DynamoDB, with integration tests using DynamoDB Local container
• Fragments Data stored in Amazon S3, with integration tests using LocalStack container
• fragments server data model configurable via .env to run using either MemoryDB or AWS (S3, DynamoDB)
• POST /fragments can create any supported text, image or JSON fragments, with tests. See 4.3.
• PUT /fragments:id can update an authenticated user's existing fragment, with tests. See 4.6.
• DELETE /fragments/:id can delete an authenticated user's existing fragment, with tests. See 4.8.
• GET /fragments/:id.ext allows conversion of all fragment types to other supported types. Image conversions use sharp module
• Conversion between all supported fragment types and conversions via .ext, with tests
• AWS account and ECR repository secrets properly stored in GitHub repo
• fragments Docker image automatically built and pushed to Amazon Elastic Container Registry (ECR) on every new git Tag via GitHub Actions CD workflow
• fragments Docker container automatically deployed to Elastic Beanstalk using pre-built Amazon ECR Docker image on every git tag via GitHub Actions CD workflow
• fragments server logs are streamed to Amazon CloudWatch

Front-End Web Testing UI Checklist

• Web app running on localhost and connecting to your API server running on AWS Elastic Beanstalk and authenticating via your Amazon Cognito User Pool.
• Basic support for users to create fragments of any type via the web app
• Basic support for users to view their fragments via the web app
• Basic support for users to update their existing fragments via the web app
• Basic support for users to delete their existing fragments via the web app

Submission

You are asked to submit two things:

1. A short document listing all necessary resources in your system, specifically:

   • Links to both private GitHub repos
   • Links to your public Docker Hub repos
   • Link to AWS Elastic Beanstalk hosted version of fragments API server
   • Link to successful GitHub Actions CI workflow run, showing eslint, unit tests, and Docker image publish to Docker Hub
   • Link to successful GitHub Actions CD workflow run showing integration tests, Docker image publish to Amazon ECR, and deploy to AWS Elastic Beanstalk
   • Screenshot of running npm run coverage to show that you've been able to properly cover the majority of your files and lines of code. Make sure your coverage rate is high enough to reflect proper testing for all units of code (>80% and includes all necessary files).
   • List of deficiencies: any known bugs, unsupported spec requirements, missing tests, or other issues that you did not, or could not complete. Discuss what still needs to be done in order to complete these.

2. A video demonstration and walk-through of your system, uploaded as a private video to YouTube (i.e., only the people you share the URL with will be able to see it). The presentation video should be between 5-10 minutes in length (no longer). It should include audio of you talking and a screen-capture of all the elements you discuss (i.e., you don’t have to be on camera if you aren’t comfortable doing so, it’s up to you). Use the video to give a walk-through of your final, completed system and all the technologies it uses.

Your walkthrough should include the following:

• Your fragments API server running on AWS Elastic Beanstalk (i.e., shows health check JSON response, with AWS EC2 URL in the browser or via curl)
• Your fragments-ui web app running on localhost and connecting to a Docker Container running on AWS Elastic Beanstalk and your Amazon Cognito User Pool, doing the following:
  • User authenticating with Cognito Hosted UI and showing the metadata for all of their existing fragments
  • User creating a new JSON fragment
  • User creating a new Text fragment (e.g., text, HTML, Markdown)
  • User creating a new Image fragment
  • User converting between text fragment types (e.g., Markdown -> HTML)
  • User converting between image fragment types (e.g., PNG -> JPEG)
  • User modifying an existing fragment
  • User deleting an existing fragment
• Demonstrate that AWS is being used correctly. Show the user's data in S3, DynamoDB, etc. and discuss how you are using these services (e.g., prove that it works as intended).

Submit the URL to your YouTube video, and try accessing it in an Incognito/Private Browser Window to make sure it's accessible to your professor.

Source control should not include /build directory

• 4.4 GET /fragments supporting both with ?expand=1 and without, with tests
• 4.7 GET /:id/info with tests