This is the capstone project of Udacity's Full Stack Development Nanodegree

The building of frontend would take some time because of npm install. Grab a coffee and have a break before you continue!

docker-compose build

First, identify backend instance by typing the following command. Select the one whose name contains backend

docker ps -a

Then, enter the instance and initialize DB data by typing:

# enter backend instance:
docker exec -it workspace_backend_1_ab7efdf943c8 bash
# init db:
flask init-db

Make sure the following ports are not used on local host:

• localhost:58100 This port will be used by frontend APP
• localhost:50080 This port will be used by backend for easy debugging
• localhost:58080 This port will be used by PG adminer for easy database administration

Launch the system using docker-compose. Note:

• The frontend and the backend will communicate using host network
• The backend will communicate with PGSQL DB using docker compose internal network

docker-compose up

All the 5 API endpoints are covered by test cases. For the drinks resource, the coverage rate is 86%. See Python Unittest Testcases and POSTman Testcases for details.

First, identify backend instance by typing the following command. Select the one whose name contains backend

docker ps -a

Then, enter the instance and execute the tests by typing:

# enter backend instance:
docker exec -it workspace_backend_1_ab7efdf943c8 bash
# run tests:
flask test

Test coverage analysis is also enabled. Use the following command to get the coverage analysis report:

# inside backend instance, type:
flask test --coverage=True

The test runner and the results for the three roles(public, barista and manager) are all kept in POSTman Testcases

• Use of correct data types for fields
• Use of primary and optional foreign key ids

• Does not use raw SQL or only where there are not SQLAlchemy equivalent expressions
• Correctly formats SQLAlchemy to define models
• Creates methods to serialize model data and helper methods to simplify API behavior such as insert, update and delete.

• RESTful principles are followed throughout the project, including appropriate naming of endpoints, use of HTTP methods GET, POST, and DELETE
• Routes perform CRUD operations

• Specifies endpoints and behavior for at least:
  • Two GET requests
  • One POST request
  • One PATCH request
  • One DELETE request
• Utilize the @app.errorhandler decorator to format error responses as JSON objects for at least four different status codes

• Project includes a custom @requires_auth decorator that:
  • Get the Authorization header from the request
  • Decode and verify the JWT using the Auth0 secret
  • Take an argument to describe the action, i.e. @require_auth(‘create:drink’)
  • Raise an error if:
    • The token is expired
    • The claims are invalid
    • The token is invalid
    • The JWT doesn’t contain the proper action
• Project includes at least two different roles that have distinct permissions for actions. These roles and permissions are clearly defined in the project README. Students can reference the Casting Agency Specs in the Specifications section of this rubric as an example.

• Includes at least one test for expected success and error behavior for each endpoint using the unittest library
• Includes tests demonstrating role-based access control, at least two per role.

Auth0 is set up and running at the time of submission. All required configuration settings are included in a bash file which export:

• The Auth0 Domain Name
• The JWT code signing secret
• The Auth0 Client ID

• Roles and permission tables are configured in Auth0.
• Access of roles is limited. Includes at least two different roles with different permissions.
• The JWT includes the RBAC permission claims.

• API is hosted live via Heroku
• URL is provided in project README
• API can be accessed by URL and requires authentication

Instructions are provided in README for setting up authentication so reviewers can test endpoints at live application endpoint