FastAPI Backend

As a reminder, the FastAPI code might be found under app-api/api.

Step 1: Create the FastAPI application, where we configured the docs, the CORS middleware and the endpoints root API router.

Step 2: Define the Settings class. The scope of this class is to carry all of the constants and configurations you wish across your API code, similar to:

• generic configurations: the port, log level or version,
• GCP credentials: bucket name or path to the JSON service account keys.

You’ll use the Settings object across the project using the get_settings() function.

Also, contained in the Config class, we programmed FastAPI to search for a .env file in the present directory and cargo all of the variables prefixed with APP_API_.

As you’ll be able to see within the .env.default file, all of the variables start with APP_API_.

Step 3: Define the schemas of the API data using Pydantic. These schemas encode or decode data from JSON to a Python object or vice versa. Also, they validate the kind and structure of your JSON object based in your defined data model.

When defining a Pydantic BaseModel, it is important so as to add a kind to each variable, which shall be used on the validation step.

Step 4: Define your endpoints, in web lingo, often known as views. Often, a view has access to some data storage and based on a question, it returns a subset of the information source to the requester.

Thus, an ordinary flow for retrieving (aka GET request) data looks like this:

“client → request data → endpoint → access data storage → encode to a Pydantic schema → decode to JSON → respond with requested data”

Let’s examine how we defined an endpoint to GET all the patron types:

We used “gcsfs.GCSFileSystem” to access the GCS bucket as an ordinary filesystem.

We attached the endpoint to the api_router.

Using the api_router.get() Python decorator, we attached a basic function to the /consumer_type_values endpoint.

In the instance above, when calling “https://:8001/api/v1/consumer_type_values” the consumer_type_values() function shall be triggered, and the response of the endpoint shall be strictly based on what the function return.

One other essential thing is to focus on that by defining the response_model (aka the schema) within the Python decorator, you haven’t got to create the Pydantic schema explicitly.

In case you return a dictionary that’s 1:1, respecting the schema structure, FastAPI will mechanically create the Pydantic object for you.

That is it. Now we are going to repeat the identical logic to define the remainder of the endpoints. FastAPI makes all the things really easy and intuitive for you.

Now, let’s take a have a look at the entire views.py file, where we defined endpoints for the next:

• /health → health check
• /consumer_type_values → GET all possible consumer types
• /area_values → GET all possible area types
• /predictions/{area}/{consumer_type} → GET the predictions for a given area and consumer type. Note that using the {} syntax, you’ll be able to add parameters to your endpoint — FastAPI docs [2].
• /monitoring/metrics → GET the aggregated monitoring metrics
• /monitoring/values/{area}/{consumer_type} → GET the monitoring values for a given area and consumer type

I need to focus on again that the FastAPI backend only reads the GCS bucket’s predictions. The inference step is completed solely within the batch prediction pipeline.

You may also go to “http://:8001/api/v1/docs“ to access the Swagger docs of the API, where you’ll be able to easily see and test all of your endpoints:

Thats it! Now you recognize the right way to construct a FastAPI backend. Things might get more complicated when adding a database layer and user sessions, but you learned all of the predominant concepts that may get you began!