Now you understand your database, how will this change how you design your API?
You should write this app in TDD style. This project will help you understand how to do this. The user stories are re-expressed as acceptance criteria, and then the acceptance criteria is re-expressed as tests. Look in the /tests folder to see the example.
When you go to Final Projects, you will save yourself a lot of time by writing your API in this way. You will also find it much easier to share the work, as each acceptance criteria could be met by a different team member, using the feature branch workflow.
Quality check!
In this project, you must write the test first.
It's better to turn in a smaller set of user stories than to turn in untested features.
If you're running out of time, scope down your application rather than commit untested code. Cut your scope, not your quality. Include a list of the stories you did, and didn't, get to in your PR message.
Maximum time in hours
10
How to get help
Share your blockers in your class channel. Use the opportunity to refine your skill in Asking Questions like a developer.
If you're struggling with the feature branch workflow, you won't be alone. There are workshops available -- do one together in class.
How to submit
Fork to your Github account.
Make a new branch named E-Commerce-API
For each user story, make a feature branch like this feature/1-list-all-products
Complete your user story, make sure the test is passing, then merge into your E-Commerce-API branch
When you are ready, open a PR to the CYF repo, following the instructions in the PR template.
gitGraph
commit id: "e-commerce-api"
branch e-commerce-api
branch feature/1-list-all-products
commit id: "assert api should return list"
commit id: "make api return list"
checkout e-commerce-api
merge feature/1-list-all-products
branch feature/2-filter-product-list
commit id: "assert api should filter list"
commit id: "make api filter list"
commit id: "check query works"
checkout e-commerce-api
merge feature/2-filter-product-list
How to review
For someone else to check out your code, they will need your .env file. Use https://onetimesecret.com/ to share this.
From Module-Databases created by SallyMcGrath: CodeYourFuture/Module-Databases#11
Link to the coursework
https://github.com/CodeYourFuture/Module-Databases/tree/main/E-Commerce-API
Why are we doing this?
Now you understand your database, how will this change how you design your API?
You should write this app in TDD style. This project will help you understand how to do this. The user stories are re-expressed as acceptance criteria, and then the acceptance criteria is re-expressed as tests. Look in the /tests folder to see the example.
When you go to Final Projects, you will save yourself a lot of time by writing your API in this way. You will also find it much easier to share the work, as each acceptance criteria could be met by a different team member, using the feature branch workflow.
Quality check!
In this project, you must write the test first.
It's better to turn in a smaller set of user stories than to turn in untested features.
If you're running out of time, scope down your application rather than commit untested code. Cut your scope, not your quality. Include a list of the stories you did, and didn't, get to in your PR message.
Maximum time in hours
10
How to get help
Share your blockers in your class channel. Use the opportunity to refine your skill in Asking Questions like a developer.
If you're struggling with the feature branch workflow, you won't be alone. There are workshops available -- do one together in class.
How to submit
How to review
For someone else to check out your code, they will need your .env file. Use https://onetimesecret.com/ to share this.
Anything else?
https://blog.gitguardian.com/secrets-api-management/ https://www.youtube.com/watch?v=JUpKDkb4Zhc