FastAPI on Cloud Run

Key Takeaways

I have only written fairly simple cloud run services in Python. How would I write a realworld service? Let me show you how. [Music] Welcome to the show, Muslim. Uh, what do you do for a living? Thanks for having me, Martin. I am a Google developer expert in cloud docker captain and co at group B which is an enterprise software delivery company. Cool. What does the title CDO mean? It means chief data officer. I help clients with data platform architecture, CI/CD pipelines, lending zone and GCP best practices. And what do you do as a Google developer expert? I support the tech community by giving talks at conferences and by publishing videos, articles and libraries. My talk and content focus on Google cloud data devops and engineering. Excellent. Excellent. Now tell me about the real world cloud run service you mentioned at the beginning of this episode. Okay. In my job, I have built many APIs in cloud run. This APIs are called by other services and I move and process data. I couldn't bring any code I wrote for a real client. So I wrote a football related service that is similar. Nice. What does your service do? It reads football statistics from a file in cloud storage. applies business rules and write the results to a bigquery table. Right? I've written code just like that. It reads, processes, and then stores data. I haven't done it for any football soccer data though. Yeah, I wanted to make this example more fun, so I picked football statistics. Anyway, I wrote an API. So my code uses fest API and it's realistic because it uses multiple Python files. I like that. That's more realistic than the single file hello world examples that you can find in the cloud run documentation. Yeah, there is nothing wrong with this simple hello world examples, but I wanted to show what a real API would look like. It uses fest API and uvicorn for serving API calls. Pyonink for validating requests and cloud build for building and deploying the application. Cool. Uh so what does your service look like when it runs? Here is the deploy cloud run service. You can access the API by visiting the service URL and view the interactive documentation by appending docs to the URL. This API is built with with faci which is based on the open API standard. That looks very useful. Uh it looks like your API is public and open to the internet. Yes, it is. But you can also test a private API by setting up a proxy on your local machine. Here is the command line for it. Got it. Uh there's a button there that says try it out. Yes, there is. Let's click it. Now I can call the API from the autogenerated docs. The service take a list of football team slogans. Let me pass sum in. Then I click execute. So now uh your API has been called and your service runs. That's right. And there is the response. The response body contains a message saying that the data has been loaded in BigQuery. And here are the response either. And what did the code behind your API do? It loaded a file from cloud storage. Here it is. The file contains all the statistics for a soccer team. In this case is space G which is a team from Paris. Then it combine that with the team slogan from the HTTP request that I made. It's combined the data from cloud storage file and from the HTTP request to calculate the total number of goals per team, the top scorer, the best passer and the dislo of the team. The clan service then writes the result to bequery and here is the JSON result and you organize the code just like you would when you're working on one of groupies clients, right? Uh what does that look like? Here is the directory structure. Most of the files are in this team league directory which represents one cloud run service. If my application included multiple cloudon service, I would have more directories at this level. Got it. Inside team league there is a service directory that contains a docker file. It also has the file main.py py which is the entry point and which imports the other Python files. Is that where the incoming HTTP requests are handled? That's right. Here is the endler. It reads some environment variables. Then it reads the JSON file from cloud storage. And here is the logic that transform the input file to output data. And here the output data is written to BigQuery. Ah and it looks like the data transformation is a pipeline of operations uh using functional programming. Yes. By putting operations together in a pipe like this. Each operation can be simple and easy to write and the code is consist and expressive. I use the tools library for for the pipe and I see that there's something called uh teamstats.computee test stats in the pipeline. Uh where is that defined? Over here in the domain directory that's where I keep the data classes for the entities in this application like team scorer row. I like that. So your domain logic is separate from the HTTP handlers. And yes, this is influenced by domain driven design. In my experience, this pattern is really useful for real world applications with many business rules. By breaking out data classes and their business rules, it's easier to read and understand them. Thank you for showing us this, Muslim. I have some questions for you. Go ahead, Martin. Now that you have the code, how do you deploy it to Cloud Run? Most Google Cloud examples use J-Cloud build submits to build the container and publish it to artifact registry. In our use case, we want to meet two conditions. Have a separate Docker file in a subfolder for each cloud run service. Keep the Docker build context and working directory at the root of the project. Got it. And how would you actually build it? There are two ways to do this. locally or through a CI/CD pipeline. For the local method, if Docker is installed on your local machine, you can navigate to the project roots, set the required environment variables, and run the appropriate Docker commands. All right, let's take a tea break while that runs. When the container has been built, I can run this command to deploy it to Cloud Run. All right, another tea break. And it's done. I can go to the Fest API docs page. Click to button to try the API. Enter a payload and submit. And there is the message that shows that it works. Very good. You ran the run and deploy commands manually. Looks like yes, I did. If you prefer to handle the build and deployment through a CI/CD pipeline, you can do so using cloud build configured via a YAML file. And when would that pipeline run? There are two ways of triggering the build. manually when a user clicks on button or automatically when a developer commits source code. In either case, we first need to create a cloud build trigger. Here is the command to create a manual trigger. And here is the command to create an automatic trigger. All right. Uh this sounds very useful. Yes, I think FETS API makes it a lot easier to build APIs and it's easy to deploy this APIs on cloud run. Thank you for sharing all this with us Muslim. Thank you for having me Martin and thank you everyone for watching. If you have any questions for Muslim or me, ask in the comments below. Also, please let me know what you thought of this episode. I love hearing from you and I read every single comment. Now go build some great APIs on Cloud Run with Fast API. [Music]