Object/relational mapping is the Vietnam of Computer Science. – T. Neward (The Vietnam of Computer Science, June 6, 2006; for an archive link and commentary, see: Object-Relational Mapping is the Vietnam of Computer Science, J. Atwood, June 26, 2006)

I am getting frustrated by the number of people calling any HTTP-based interface a REST API. Today’s example is the SocialSite REST API. That is RPC. It screams RPC. There is so much coupling on display that it should be given an X rating. – R.T. Fielding, Untangled, 2010.

In this lab, you’ll build a web-based data service.

Building a Data Service

Azure supports NodeJS applications that implement Web data services.

Exercise 9.1

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.

  1. On GitHub, fork the sample Monopoly data service repo (for details on how to do this, see Forking a repository). Notes:

    • Give your forked version of the repo a unique name and plan to maintain it as a stand-alone repo, separate from your standard cs262 repo. It will be easier to implement the CI/CD for your Web service this way.
    • Review the contents of the repo, noting the following:
      • 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.
  2. On Azure, in the list of App Services, Create a new “Web App” and configure it as follows.

    1. Basics
      • Subscription/Resource Group: Use your free student account and your existing resources group.
      • Name: Allow the system to give your service a unique name (e.g., the sample monopoly service URL).
      • Runtime stack: Choose a Node-based stack that’s compatible with the service settings (e.g., version 22).
      • Pricing plan: Choose a free pricing plan (e.g., “Free F1 (shared infrastructure)”).
      Leave the other settings as is; we’ll configure CI/CD after the service is created.

    2. Review + create the app.
  3. On Azure, in your new app service, do the following:

    1. Under Deployment CenterSettings:
      • Choose CI/CD GitHub deployment.
      • Authorize access to your GitHub account by following the GitHub login procedure and being sure to “Grant” access to any GitHub organization that holds your Web app repo.
      • Enter your (forked) GitHub service repo details.
      Be sure to “Save” these settings. This will create a GitHub workflow file in your service repo (in .github/workflows/.) that will automatically deploy your service to Azure whenever you push changes to the main branch of your service repo.

    2. Under SettingsEnvironment variables, add separate key-value pairs for your Azure PostgreSQL database:
      • DB_SERVER — See the “Endpoint” name in your PostgreSQL database instance (e.g., cs262.postgres.database.azure.com).
      • DB_PORT — For PostgreSQL this is always 5432.
      • DB_USER — See the PostgreSQL administrator login (e.g., cs262).
      • DB_PASSWORD — Hopefully, you remember this!
      • DB_DATABASE — See the “Databases” page (e.g., postgres).
      Be sure to apply the settings. Note that this approach allows us to keep these (sensitive) values out of our (public) GitHub repo.

    Restart the App service to apply these changes.

  4. On Azure PostgreSQL, do the following:

    1. Under SettingsServer parameters, set the value of 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.

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).

Team Work

Running a Sprint Retrospective and Planning Session

Be sure to consider your preliminary design presentation as part of this planning exercise.

Exercise 9.2

You should actively participate in your team’s retrospective and planning session.

Checking in