In this lab, you’ll build a web-based data service.
Azure supports NodeJS applications that implement Web data services.
Create an Azure Web data service to your monopoly database (created in lab 7) using the Monopoly data service as a model. Creating Web data services is a bit trickly so you’ll reimplement a copy of the sample as follows.
On GitHub, fork the sample Monopoly data service repo (for details on how to do this, see Forking a repository). Notes:
cs262
repo. It will be easier
to implement the CI/CD for your Web service
this way.
README.md
— This documents
the sample data service; try it out using the
browser.src/monopolyService.ts
— This
script implements the REST data service.scripts/test-cli.http
— This
file lists the curl commands demoed in class.
src/monopolyDirect.ts
— This
script implements the direct-to-PostgreSQL
access
for the Monopoly game data demoed in class..github/workflows/.
— Azure
Webservices automatically (re)builds the
CI/CD scripts in this sub-directory.
On Azure, in the list of App Services, Create a new “Web App” and configure it as follows.
On Azure, in your new app service, do the following:
.github/workflows/.
) that will
automatically deploy your service to Azure whenever you
push changes to the main branch of your service repo.
cs262.postgres.database.azure.com
).
5432
.
cs262
).
postgres
).
Restart the App service to apply these changes.
On Azure PostgreSQL, do the following:
require_secure_transport
to “OFF”.
Restart the PostgreSQL service to apply this change.
Make sure that your service is running (n.b., you can the URL in the
Azure web app “Overview” page) and that it provides all
the API endpoints listed in the sample service README. Finally,
update your README.md
file to link your service URL.
For grading purposes, do the following.
cs262/lab09/your-service-fork
sub-directory in your
standard course repo:
README.md
file,
which should include a hyperlink to the root of your
running data service on Azure.
monopolyService.ts
).
.github/workflows/master_cs262.yml
).
If you get server errors (e.g., HTTP 500 Internal Server Error), there is something going wrong with Web app, often a database access error. The Web server won’t return details because that would give away important details about the service to the public. You, as the developer, can see the actual error by going to the Web service and checking the execution log stream. E.g., for Azure, look under the Overview (tab on the top) → Logs (tab toward the bottom in the middle).
Be sure to consider your preliminary design presentation as part of this planning exercise.
You should actively participate in your team’s retrospective and planning session.