CSci 3081W: Program Design and Development Homework 01(A) & 02(B+C) – Microservices Spring 2022 Due Dates: ● Documented Web Service API – Sunday, February 13, 2021 before 11:59pm. ● Program Design & Peer Reviews – Sunday, February 27, 2021 before 11:59pm. Overview: This homework teaches how to build and deploy your own microservice API and document it for other users. Instructions: This homework is mostly a writing assignment. To receive credit for this homework, you will need to deploy a documented web service API to Docker Hub. You will submit your Docker Hub URL in your Canvas Lab Section Assignments Page. After this, you will write about how to build a useful program using other web services, written by your fellow classmates. You will submit a document containing your answers for Parts B and C in the Homework 2 Canvas submission. This assignment is separated into three parts (Part A, Part B, and Part C). In Part A, starting with examples we will create a simple web service API, deploy it to Docker Hub, and document the service (Part A is due 2/13). In Part B you will be given web services to peer review from other students. You will draw a flowchart of how you would use these web services to build a larger program. Using the diagram, you will write an explanation for your system. In Part C, you will provide a two paragraph peer review for two of the APIs from other students. Goal: Build and document a docker container microservice and explore interaction with other microservices. What you’ll learn: 1. How to install docker on your home machines. 2. How to use docker on the CSE Lab Machines. 3. How to build and run a docker image. 4. How to push a docker image to Docker Hub. 5. How to document your API using markdown on Docker Hub. 6. How to write a simple peer review. Part A – Building a Web Service API using Docker Due Date: Sunday, February 13, 2021 before 11:59pm. In Part A you will build your own microservice using NodeJS or Python Flask and deploy it to Docker Hub. You will also document your API thoroughly on the Docker Hub page using Markdown. Before beginning, go through the Docker Tutorial in the following link to learn how to build, run, and deploy docker images in several environments: ● Docker Tutorial: https://docs.google.com/document/d/1woqNJ3c-syRzXH63jx-6ATzJi9R-_fXP-DG FWigA3io/edit usp=sharing Choose a language and template to start with. Here are two example ATM microservices in NodeJS and Python. You may use another language or platform to build your API as long as you can deploy it to Docker Hub. It is suggested that you start with one of the following: ● Node JS Example: ○ https://github.umn.edu/umn-csci-3081-s22/examples/tree/main/lectures/04 -docker/nodejs_example ● Python Flask Example: ○ https://github.umn.edu/umn-csci-3081-s22/examples/tree/main/lectures/04 -docker/flask_example Notice that the Node JS and the Python Flask example produce the same API, just in different languages. You may choose either of these as a starting point. Task: Create your own simple microservice using a combination of 4 or 5 GET / POST requests. Your API could do anything useful. The above examples implement a simple one user ATM. Here are some ideas worth implementing (although certainly not exhaustive): ● Coffee Transactions ● Calorie Counting ● Friend List ● Current Weather ● Book Categorization ● Simple Calculator ● Metro Transit Status ● Address Book ● etc… Feel free to be creative. Your API could call other public APIs or do something trivially simple (for example the ATM above is simple). Deploy to Docker Hub In order to avoid port clashes, in the Dockerfile, change the EXPOSE to some other number other than 8081 (so not everyone is using the same port). Using your own machine or CSE Labs qemu build and push your docker image to Docker Hub: docker build -t /hw1_api . docker push /hw1_api Note: that if you are using CSELabs to run docker, you must be using qemu to build and singularity to run a docker image; you cannot run docker commands on a lab computer/image itself due to security concerns. Examples: To run qemu on VOLE/ssh: /project/qemu/bin/vm-start -n dockerhost -p ${RANDOM} To pull an image using singularity: singularity pull docker:/// To run an image using singularity: singularity run docker:/// Note: Singularity uses a large amount of space on the lab machines. In order to combat this, when finished, use rm -rf *.sif as well as singularity cache clean in a lab terminal. More information at: https://cse.umn.edu/cseit/self-help-guides/disk-quota-free-your- space Upload the link to your hw1_api repository on Docker Hub. It should look like the following: https://hub.docker.com/r//hw1_api Finally, go to your hw1_api repository on Docker Hub (the link above). Edit the description and Readme to document your API: You should detail how to download your image and run a container. You should provide an overview of your microservice along with a detailed description of how to run each function. Consider writing to an audience who does not know anything about your API or what it does. Here is a basic syntax guide for “Markdown”, the formatting language for editing your Readme: https://www.markdownguide.org/basic-syntax/ Note: Your API does not need to be super sophisticated or powerful. However, creative ideas are welcome. Grading Criteria For Part A, we will be grading your documentation on Docker Hub. It is important that you clearly explain how to run and use your API. We will also take into consideration the anonymous feedback from your peers (from Part C) of the assignment. Make sure you also provide a good description and overview of the problem your API solves. Part B – Design a Program Due Date: Sunday, February 27, 2021 before 11:59pm. You will be asked to peer review each other’s APIs. For each API, download the docker image and run on your local machine or using SSH and Singularity on the lab machines (See Docker Tutorial). Read the documentation for each API and try to call the API functions to understand how the system works. Design a program that uses the APIs provided to you by your peers (combining as much functionality as possible). The deliverable will be a simple flowchart describing how the API calls fit into your program. Here is an example flowchart from the BlenderGIS program we talked about during Workshop 1: https://raw.githubusercontent.com/wiki/domlysz//flowchart.jpg. It should detail which calls are made.blenderGIS Explain your flowchart in words, referring to the visual in your writing. Figures are essential to good writing and this exercise will help you practice using them. Turn in: A short document that includes the flowchart figure along with the explanation of your program using the figure. Grading Criteria For Part B, we will be grading your flowchart diagram and how well you explain your new program’s design. Be sure to reference your figure multiple times in your text so that readers can understand your approach using the diagram. Part C – Peer Review Due Date: Sunday, February 27, 2021 before 11:59pm. Peer reviews are a great way to learn how to write. If something doesn’t make sense to you, it probably is because it could be written better. Learn from others and how you can improve your writing based on feedback. For each API you are assigned, you should write a short peer review of the Docker Hub documentation. Your peer review should include the following three paragraphs: 1. Summary – Provide a quick summary of the API documentation. What does it do and how would you utilize it What are its key contributions, advantages, and disadvantages 2. Review – What worked and what did not What areas are confusing How could the writing be improved to clarify the API Provide any major issues you ran into when trying to use the API. Would you change anything Please be respectful and kind in your review. Write it to help improve the writing for everyone (both the author and other users). 3. Minor Issues – Provide a list of spelling, grammar, organization, or content that could improve the writing. Grading Criteria For Part C, we will be grading your peer review. Did you respectfully and adequately provide useful feedback to each original author There is usually something that is unclear or could be improved.
