As **FastAPI** is based on the OpenAPI specification, you get automatic compatibility with many tools, including the automatic API docs (provided by Swagger UI).
Because **FastAPI** is based on the **OpenAPI** specification, its APIs can be described in a standard format that many tools understand.
One particular advantage that is not necessarily obvious is that you can **generate clients** (sometimes called <abbrtitle="Software Development Kits">**SDKs**</abbr> ) for your API, for many different **programming languages**.
This makes it easy to generate up-to-date **documentation**, client libraries (<abbrtitle="Software Development Kits">**SDKs**</abbr>) in multiple languages, and **testing** or **automation workflows** that stay in sync with your code.
## OpenAPI Client Generators
In this guide, you'll learn how to generate a **TypeScript SDK** for your FastAPI backend.
There are many tools to generate clients from **OpenAPI**.
## Open Source SDK Generators
A common tool is<ahref="https://openapi-generator.tech/"class="external-link"target="_blank">OpenAPI Generator</a>.
A versatile option is the<ahref="https://openapi-generator.tech/"class="external-link"target="_blank">OpenAPI Generator</a>, which supports **many programming languages** and can generate SDKs from your OpenAPI specification.
If you are building a **frontend**, a very interesting alternative is<ahref="https://github.com/hey-api/openapi-ts"class="external-link"target="_blank">openapi-ts</a>.
For **TypeScript clients**,<ahref="https://heyapi.dev/"class="external-link"target="_blank">Hey API</a> is a purpose-built solution, providing an optimized experience for the TypeScript ecosystem.
## Client and SDK Generators - Sponsor
You can discover more SDK generators on <ahref="https://openapi.tools/#sdk"class="external-link"target="_blank">OpenAPI.Tools</a>.
There are also some **company-backed** Client and SDK generators based on OpenAPI (FastAPI), in some cases they can offer you **additional features** on top of high-quality generated SDKs/clients.
/// tip
FastAPI automatically generates **OpenAPI 3.1** specifications, so any tool you use must support this version.
///
## SDK Generators from FastAPI Sponsors
This section highlights **venture-backed** and **company-supported** solutions from companies that sponsor FastAPI. These products provide **additional features** and **integrations** on top of high-quality generated SDKs.
Some of them also ✨ [**sponsor FastAPI**](../help-fastapi.md#sponsor-the-author){.internal-link target=_blank} ✨, this ensures the continued and healthy **development** of FastAPI and its **ecosystem**.
By ✨ [**sponsoring FastAPI**](../help-fastapi.md#sponsor-the-author){.internal-link target=_blank} ✨, these companies help ensure the framework and its **ecosystem** remain healthy and **sustainable**.
And it shows their true commitment to FastAPI and its **community** (you), as they not only want to provide you a **good service** but also want to make sure you have a **good and healthy framework**, FastAPI. 🙇
Their sponsorship also demonstrates a strong commitment to the FastAPI **community** (you), showing that they care not only about offering a **great service** but also about supporting a **robust and thriving framework**, FastAPI. 🙇
There are also several other companies offering similar services that you can search and find online. 🤓
Some of these solutions may also be open source or offer free tiers, so you can try them without a financial commitment. Other commercial SDK generators are available and can be found online. 🤓
## Generate a TypeScript Frontend Client
## Create a TypeScript SDK
Let's start with a simple FastAPI application:
@ -38,78 +46,31 @@ Notice that the *path operations* define the models they use for request payload
### API Docs
If you go to the API docs, you will see that it has the **schemas** for the data to be sent in requests and received in responses:
If you go to `/docs`, you will see that it has the **schemas** for the data to be sent in requests and received in responses:
This will generate a TypeScript SDK in `./src/client`.
To generate the client code you can use the command line application `openapi-ts` that would now be installed.
You can learn how to <ahref="https://heyapi.dev/openapi-ts/get-started"class="external-link"target="_blank">install `@hey-api/openapi-ts`</a> and read about the <ahref="https://heyapi.dev/openapi-ts/output"class="external-link"target="_blank">generated output</a> on their website.
Because it is installed in the local project, you probably wouldn't be able to call that command directly, but you would put it on your `package.json` file.
@ -170,13 +131,13 @@ But I'll show you how to improve that next. 🤓
You can **modify** the way these operation IDs are **generated** to make them simpler and have **simpler method names** in the clients.
In this case you will have to ensure that each operation ID is **unique** in some other way.
In this case, you will have to ensure that each operation ID is **unique** in some other way.
For example, you could make sure that each *path operation* has a tag, and then generate the operation ID based on the **tag** and the *path operation***name** (the function name).
### Custom Generate Unique ID Function
FastAPI uses a **unique ID** for each *path operation*, it is used for the **operation ID** and also for the names of any needed custom models, for requests or responses.
FastAPI uses a **unique ID** for each *path operation*, which is used for the **operation ID** and also for the names of any needed custom models, for requests or responses.
You can customize that function. It takes an `APIRoute` and outputs a string.
@ -188,7 +149,7 @@ You can then pass that custom function to **FastAPI** as the `generate_unique_id
### Generate a TypeScript Client with Custom Operation IDs
Now if you generate the client again, you will see that it has the improved method names:
Now, if you generate the client again, you will see that it has the improved method names:
@ -202,7 +163,7 @@ We already know that this method is related to the **items** because that word i
We will probably still want to keep it for OpenAPI in general, as that will ensure that the operation IDs are **unique**.
But for the generated client we could **modify** the OpenAPI operation IDs right before generating the clients, just to make those method names nicer and **cleaner**.
But for the generated client, we could **modify** the OpenAPI operation IDs right before generating the clients, just to make those method names nicer and **cleaner**.
We could download the OpenAPI JSON to a file `openapi.json` and then we could **remove that prefixed tag** with a script like this:
@ -220,24 +181,10 @@ With that, the operation IDs would be renamed from things like `items-get_items`
### Generate a TypeScript Client with the Preprocessed OpenAPI
Now as the end result is in a file `openapi.json`, you would modify the `package.json` to use that local file, for example:
After generating the new client, you would now have **clean method names**, with all the **autocompletion**, **inline errors**, etc:
@ -246,7 +193,7 @@ After generating the new client, you would now have **clean method names**, with
## Benefits
When using the automatically generated clients you would get **autocompletion** for:
When using the automatically generated clients, you would get **autocompletion** for:
* Methods.
* Request payloads in the body, query parameters, etc.
@ -256,6 +203,6 @@ You would also have **inline errors** for everything.
And whenever you update the backend code, and **regenerate** the frontend, it would have any new *path operations* available as methods, the old ones removed, and any other change would be reflected on the generated code. 🤓
This also means that if something changed it will be **reflected** on the client code automatically. And if you **build** the client it will error out if you have any **mismatch** in the data used.
This also means that if something changed, it will be **reflected** on the client code automatically. And if you **build** the client, it will error out if you have any **mismatch** in the data used.
So, you would **detect many errors** very early in the development cycle instead of having to wait for the errors to show up to your final users in production and then trying to debug where the problem is. ✨