Post-Deployment API Testing

1. Locating Your Deployed Service URL

After a successful deployment, Google Cloud Run assigns a unique, permanent URL to your service. You'll need this URL to send requests to your API. There are a few ways to find it:

• From the deployment command output: The gcloud run deploy command prints the service URL upon successful completion.
• From the Google Cloud Console: Navigate to Cloud Run in your project, click on your service, and the URL will be displayed prominently at the top of the service details page.
• Using the gcloud CLI: This is a reliable and scriptable way to retrieve the URL at any time.

The following resource provides a concise guide on deploying and then retrieving the service URL.

To get your service's URL, you can run a similar command, replacing helloworld-fastapi with your service name and specifying your region:

gcloud run services describe [YOUR_SERVICE_NAME] \
    --region [YOUR_REGION] \
    --format="value(status.address.url)"

Store this URL, as we will use it for all the tests in this lesson.

2. Testing with the Interactive API Docs (Swagger UI)

One of the best features of FastAPI is its automatically generated interactive documentation. Just like you did during local development, you can use the live Swagger UI to test your endpoints. This is often the quickest way to perform a sanity check.

1. Open a web browser and navigate to [YOUR_SERVICE_URL]/docs.
2. You should see the familiar Swagger UI, listing all the endpoints you've created.
3. You can expand an endpoint, click "Try it out", fill in any required parameters, and click "Execute".

The following video demonstrates this exact process on a deployed Cloud Run service.

Try this now with the /info endpoint we created in the last lesson. You should receive a 200 OK response with the body {"environment":"production"}, confirming that your app is running and correctly reading the environment variable you configured.

3. Testing from the Command Line with curl

While the Swagger UI is great for interactive testing, curl is an indispensable tool for more rigorous, scriptable, and non-browser-based testing. It allows you to craft and send any kind of HTTP request directly from your terminal.

Testing a GET Endpoint

This is the simplest test. Let's call your /info endpoint.

# Replace [YOUR_SERVICE_URL] with the URL you retrieved earlier
curl [YOUR_SERVICE_URL]/info

You should see the JSON response printed directly to your terminal: {"environment":"production"}.

Testing an Endpoint with a Request Body

If you have a POST or PUT endpoint that expects a JSON body (like the ones you built in the database modules), curl can send that data using the -X flag for the method, the -H flag for the Content-Type header, and the -d flag for the data payload.

For example, if you had an endpoint at /items that creates a new item, the command would look like this:

curl -X POST \
  -H "Content-Type: application/json" \
  -d '{"name": "My New Item", "price": 19.99}' \
  [YOUR_SERVICE_URL]/items

This simulates exactly what a client application would do when sending data to your API.

4. Verifying with Logs and Metrics

A successful response is a good sign, but what happens if something goes wrong? Or if you want to confirm what happened on the server side? The final piece of the testing puzzle is to inspect the service's logs and metrics in Google Cloud.

Now, let's go beyond what the user sees and look at the server's perspective.

1. Navigate to the Cloud Run dashboard in the Google Cloud Console and select your service.
2. Click on the "LOGS" tab.

Here you will see a real-time stream of logs generated by your service. After making a few test requests with your browser or curl, you should see entries corresponding to those requests, like:

INFO: 169.254.1.1:0 - "GET /docs HTTP/1.1" 200 OK
INFO: 169.254.1.1:0 - "GET /info HTTP/1.1" 200 OK

If an error occurs (e.g., a bug in your code causes a 500 Internal Server Error), the full Python traceback will appear here. This makes the logs your most important tool for debugging issues in your deployed application.

Next, click on the "METRICS" tab. Here you can see graphs for:

• Request Count: How many requests your service is receiving.
• Request Latency: How long your service takes to respond.
• Container CPU and Memory Utilization: How much resources your application is using.

These metrics are essential for monitoring your application's health and performance over time.

Course Conclusion

Congratulations! You have reached the end of the course and successfully built, containerized, configured, deployed, and tested a production-ready FastAPI application on Google Cloud Run.

Key Takeaways from this Lesson:

• You can test a live API using the same tools as local development: the interactive Swagger UI for quick checks and curl for command-line testing.
• The URL for your deployed service can be found in the gcloud command output, the Cloud Console, or by using gcloud run services describe.
• Cloud Run Logs are your primary tool for debugging live applications, providing request information and error tracebacks.
• Cloud Run Metrics give you insight into your service's performance and resource consumption.

Over this entire course, you have journeyed from the fundamentals of HTTP to deploying a sophisticated, scalable service. You now have a complete, end-to-end skill set for backend development with FastAPI, a foundation that is directly applicable to your goal of deploying AI/ML models.

What's Next?
Your journey doesn't end here. With this solid foundation, you can now explore more advanced topics:

• Full CI/CD Pipeline: Automate the entire build and deploy process using Google Cloud Build, as hinted at in some of our resources.
• Advanced FastAPI: Dive deeper into features like WebSockets, dependency overrides for complex scenarios, and custom middleware.
• Integrating a Real ML Model: Adapt the ML model serving patterns from Module 8 to load and serve one of your own pre-trained models.
• Advanced Cloud Architecture: Explore other GCP services like Cloud Storage for handling file uploads or Pub/Sub for asynchronous background tasks.

You have the skills and the practical experience. Keep building, keep learning, and thank you for taking this course