@ -1,7 +0,0 @@ |
|||
FROM python:3.9 |
|||
|
|||
RUN pip install httpx PyGithub "pydantic==1.5.1" "pyyaml>=5.3.1,<6.0.0" |
|||
|
|||
COPY ./app /app |
|||
|
|||
CMD ["python", "/app/main.py"] |
@ -1,10 +0,0 @@ |
|||
name: "Notify Translations" |
|||
description: "Notify in the issue for a translation when there's a new PR available" |
|||
author: "Sebastián Ramírez <[email protected]>" |
|||
inputs: |
|||
token: |
|||
description: 'Token, to read the GitHub API. Can be passed in using {{ secrets.GITHUB_TOKEN }}' |
|||
required: true |
|||
runs: |
|||
using: 'docker' |
|||
image: 'Dockerfile' |
@ -1,7 +0,0 @@ |
|||
FROM python:3.9 |
|||
|
|||
RUN pip install httpx PyGithub "pydantic==2.0.2" pydantic-settings "pyyaml>=5.3.1,<6.0.0" |
|||
|
|||
COPY ./app /app |
|||
|
|||
CMD ["python", "/app/main.py"] |
@ -1,10 +0,0 @@ |
|||
name: "Generate FastAPI People" |
|||
description: "Generate the data for the FastAPI People page" |
|||
author: "Sebastián Ramírez <[email protected]>" |
|||
inputs: |
|||
token: |
|||
description: 'User token, to read the GitHub API. Can be passed in using {{ secrets.FASTAPI_PEOPLE }}' |
|||
required: true |
|||
runs: |
|||
using: 'docker' |
|||
image: 'Dockerfile' |
@ -1,682 +0,0 @@ |
|||
import logging |
|||
import subprocess |
|||
import sys |
|||
from collections import Counter, defaultdict |
|||
from datetime import datetime, timedelta, timezone |
|||
from pathlib import Path |
|||
from typing import Any, Container, DefaultDict, Dict, List, Set, Union |
|||
|
|||
import httpx |
|||
import yaml |
|||
from github import Github |
|||
from pydantic import BaseModel, SecretStr |
|||
from pydantic_settings import BaseSettings |
|||
|
|||
github_graphql_url = "https://api.github.com/graphql" |
|||
questions_category_id = "MDE4OkRpc2N1c3Npb25DYXRlZ29yeTMyMDAxNDM0" |
|||
|
|||
discussions_query = """ |
|||
query Q($after: String, $category_id: ID) { |
|||
repository(name: "fastapi", owner: "fastapi") { |
|||
discussions(first: 100, after: $after, categoryId: $category_id) { |
|||
edges { |
|||
cursor |
|||
node { |
|||
number |
|||
author { |
|||
login |
|||
avatarUrl |
|||
url |
|||
} |
|||
title |
|||
createdAt |
|||
comments(first: 100) { |
|||
nodes { |
|||
createdAt |
|||
author { |
|||
login |
|||
avatarUrl |
|||
url |
|||
} |
|||
isAnswer |
|||
replies(first: 10) { |
|||
nodes { |
|||
createdAt |
|||
author { |
|||
login |
|||
avatarUrl |
|||
url |
|||
} |
|||
} |
|||
} |
|||
} |
|||
} |
|||
} |
|||
} |
|||
} |
|||
} |
|||
} |
|||
""" |
|||
|
|||
|
|||
prs_query = """ |
|||
query Q($after: String) { |
|||
repository(name: "fastapi", owner: "fastapi") { |
|||
pullRequests(first: 100, after: $after) { |
|||
edges { |
|||
cursor |
|||
node { |
|||
number |
|||
labels(first: 100) { |
|||
nodes { |
|||
name |
|||
} |
|||
} |
|||
author { |
|||
login |
|||
avatarUrl |
|||
url |
|||
} |
|||
title |
|||
createdAt |
|||
state |
|||
comments(first: 100) { |
|||
nodes { |
|||
createdAt |
|||
author { |
|||
login |
|||
avatarUrl |
|||
url |
|||
} |
|||
} |
|||
} |
|||
reviews(first:100) { |
|||
nodes { |
|||
author { |
|||
login |
|||
avatarUrl |
|||
url |
|||
} |
|||
state |
|||
} |
|||
} |
|||
} |
|||
} |
|||
} |
|||
} |
|||
} |
|||
""" |
|||
|
|||
sponsors_query = """ |
|||
query Q($after: String) { |
|||
user(login: "fastapi") { |
|||
sponsorshipsAsMaintainer(first: 100, after: $after) { |
|||
edges { |
|||
cursor |
|||
node { |
|||
sponsorEntity { |
|||
... on Organization { |
|||
login |
|||
avatarUrl |
|||
url |
|||
} |
|||
... on User { |
|||
login |
|||
avatarUrl |
|||
url |
|||
} |
|||
} |
|||
tier { |
|||
name |
|||
monthlyPriceInDollars |
|||
} |
|||
} |
|||
} |
|||
} |
|||
} |
|||
} |
|||
""" |
|||
|
|||
|
|||
class Author(BaseModel): |
|||
login: str |
|||
avatarUrl: str |
|||
url: str |
|||
|
|||
|
|||
# Discussions |
|||
|
|||
|
|||
class CommentsNode(BaseModel): |
|||
createdAt: datetime |
|||
author: Union[Author, None] = None |
|||
|
|||
|
|||
class Replies(BaseModel): |
|||
nodes: List[CommentsNode] |
|||
|
|||
|
|||
class DiscussionsCommentsNode(CommentsNode): |
|||
replies: Replies |
|||
|
|||
|
|||
class Comments(BaseModel): |
|||
nodes: List[CommentsNode] |
|||
|
|||
|
|||
class DiscussionsComments(BaseModel): |
|||
nodes: List[DiscussionsCommentsNode] |
|||
|
|||
|
|||
class DiscussionsNode(BaseModel): |
|||
number: int |
|||
author: Union[Author, None] = None |
|||
title: str |
|||
createdAt: datetime |
|||
comments: DiscussionsComments |
|||
|
|||
|
|||
class DiscussionsEdge(BaseModel): |
|||
cursor: str |
|||
node: DiscussionsNode |
|||
|
|||
|
|||
class Discussions(BaseModel): |
|||
edges: List[DiscussionsEdge] |
|||
|
|||
|
|||
class DiscussionsRepository(BaseModel): |
|||
discussions: Discussions |
|||
|
|||
|
|||
class DiscussionsResponseData(BaseModel): |
|||
repository: DiscussionsRepository |
|||
|
|||
|
|||
class DiscussionsResponse(BaseModel): |
|||
data: DiscussionsResponseData |
|||
|
|||
|
|||
# PRs |
|||
|
|||
|
|||
class LabelNode(BaseModel): |
|||
name: str |
|||
|
|||
|
|||
class Labels(BaseModel): |
|||
nodes: List[LabelNode] |
|||
|
|||
|
|||
class ReviewNode(BaseModel): |
|||
author: Union[Author, None] = None |
|||
state: str |
|||
|
|||
|
|||
class Reviews(BaseModel): |
|||
nodes: List[ReviewNode] |
|||
|
|||
|
|||
class PullRequestNode(BaseModel): |
|||
number: int |
|||
labels: Labels |
|||
author: Union[Author, None] = None |
|||
title: str |
|||
createdAt: datetime |
|||
state: str |
|||
comments: Comments |
|||
reviews: Reviews |
|||
|
|||
|
|||
class PullRequestEdge(BaseModel): |
|||
cursor: str |
|||
node: PullRequestNode |
|||
|
|||
|
|||
class PullRequests(BaseModel): |
|||
edges: List[PullRequestEdge] |
|||
|
|||
|
|||
class PRsRepository(BaseModel): |
|||
pullRequests: PullRequests |
|||
|
|||
|
|||
class PRsResponseData(BaseModel): |
|||
repository: PRsRepository |
|||
|
|||
|
|||
class PRsResponse(BaseModel): |
|||
data: PRsResponseData |
|||
|
|||
|
|||
# Sponsors |
|||
|
|||
|
|||
class SponsorEntity(BaseModel): |
|||
login: str |
|||
avatarUrl: str |
|||
url: str |
|||
|
|||
|
|||
class Tier(BaseModel): |
|||
name: str |
|||
monthlyPriceInDollars: float |
|||
|
|||
|
|||
class SponsorshipAsMaintainerNode(BaseModel): |
|||
sponsorEntity: SponsorEntity |
|||
tier: Tier |
|||
|
|||
|
|||
class SponsorshipAsMaintainerEdge(BaseModel): |
|||
cursor: str |
|||
node: SponsorshipAsMaintainerNode |
|||
|
|||
|
|||
class SponsorshipAsMaintainer(BaseModel): |
|||
edges: List[SponsorshipAsMaintainerEdge] |
|||
|
|||
|
|||
class SponsorsUser(BaseModel): |
|||
sponsorshipsAsMaintainer: SponsorshipAsMaintainer |
|||
|
|||
|
|||
class SponsorsResponseData(BaseModel): |
|||
user: SponsorsUser |
|||
|
|||
|
|||
class SponsorsResponse(BaseModel): |
|||
data: SponsorsResponseData |
|||
|
|||
|
|||
class Settings(BaseSettings): |
|||
input_token: SecretStr |
|||
github_repository: str |
|||
httpx_timeout: int = 30 |
|||
|
|||
|
|||
def get_graphql_response( |
|||
*, |
|||
settings: Settings, |
|||
query: str, |
|||
after: Union[str, None] = None, |
|||
category_id: Union[str, None] = None, |
|||
) -> Dict[str, Any]: |
|||
headers = {"Authorization": f"token {settings.input_token.get_secret_value()}"} |
|||
# category_id is only used by one query, but GraphQL allows unused variables, so |
|||
# keep it here for simplicity |
|||
variables = {"after": after, "category_id": category_id} |
|||
response = httpx.post( |
|||
github_graphql_url, |
|||
headers=headers, |
|||
timeout=settings.httpx_timeout, |
|||
json={"query": query, "variables": variables, "operationName": "Q"}, |
|||
) |
|||
if response.status_code != 200: |
|||
logging.error( |
|||
f"Response was not 200, after: {after}, category_id: {category_id}" |
|||
) |
|||
logging.error(response.text) |
|||
raise RuntimeError(response.text) |
|||
data = response.json() |
|||
if "errors" in data: |
|||
logging.error(f"Errors in response, after: {after}, category_id: {category_id}") |
|||
logging.error(data["errors"]) |
|||
logging.error(response.text) |
|||
raise RuntimeError(response.text) |
|||
return data |
|||
|
|||
|
|||
def get_graphql_question_discussion_edges( |
|||
*, |
|||
settings: Settings, |
|||
after: Union[str, None] = None, |
|||
): |
|||
data = get_graphql_response( |
|||
settings=settings, |
|||
query=discussions_query, |
|||
after=after, |
|||
category_id=questions_category_id, |
|||
) |
|||
graphql_response = DiscussionsResponse.model_validate(data) |
|||
return graphql_response.data.repository.discussions.edges |
|||
|
|||
|
|||
def get_graphql_pr_edges(*, settings: Settings, after: Union[str, None] = None): |
|||
data = get_graphql_response(settings=settings, query=prs_query, after=after) |
|||
graphql_response = PRsResponse.model_validate(data) |
|||
return graphql_response.data.repository.pullRequests.edges |
|||
|
|||
|
|||
def get_graphql_sponsor_edges(*, settings: Settings, after: Union[str, None] = None): |
|||
data = get_graphql_response(settings=settings, query=sponsors_query, after=after) |
|||
graphql_response = SponsorsResponse.model_validate(data) |
|||
return graphql_response.data.user.sponsorshipsAsMaintainer.edges |
|||
|
|||
|
|||
class DiscussionExpertsResults(BaseModel): |
|||
commenters: Counter |
|||
last_month_commenters: Counter |
|||
three_months_commenters: Counter |
|||
six_months_commenters: Counter |
|||
one_year_commenters: Counter |
|||
authors: Dict[str, Author] |
|||
|
|||
|
|||
def get_discussion_nodes(settings: Settings) -> List[DiscussionsNode]: |
|||
discussion_nodes: List[DiscussionsNode] = [] |
|||
discussion_edges = get_graphql_question_discussion_edges(settings=settings) |
|||
|
|||
while discussion_edges: |
|||
for discussion_edge in discussion_edges: |
|||
discussion_nodes.append(discussion_edge.node) |
|||
last_edge = discussion_edges[-1] |
|||
discussion_edges = get_graphql_question_discussion_edges( |
|||
settings=settings, after=last_edge.cursor |
|||
) |
|||
return discussion_nodes |
|||
|
|||
|
|||
def get_discussions_experts( |
|||
discussion_nodes: List[DiscussionsNode], |
|||
) -> DiscussionExpertsResults: |
|||
commenters = Counter() |
|||
last_month_commenters = Counter() |
|||
three_months_commenters = Counter() |
|||
six_months_commenters = Counter() |
|||
one_year_commenters = Counter() |
|||
authors: Dict[str, Author] = {} |
|||
|
|||
now = datetime.now(tz=timezone.utc) |
|||
one_month_ago = now - timedelta(days=30) |
|||
three_months_ago = now - timedelta(days=90) |
|||
six_months_ago = now - timedelta(days=180) |
|||
one_year_ago = now - timedelta(days=365) |
|||
|
|||
for discussion in discussion_nodes: |
|||
discussion_author_name = None |
|||
if discussion.author: |
|||
authors[discussion.author.login] = discussion.author |
|||
discussion_author_name = discussion.author.login |
|||
discussion_commentors: dict[str, datetime] = {} |
|||
for comment in discussion.comments.nodes: |
|||
if comment.author: |
|||
authors[comment.author.login] = comment.author |
|||
if comment.author.login != discussion_author_name: |
|||
author_time = discussion_commentors.get( |
|||
comment.author.login, comment.createdAt |
|||
) |
|||
discussion_commentors[comment.author.login] = max( |
|||
author_time, comment.createdAt |
|||
) |
|||
for reply in comment.replies.nodes: |
|||
if reply.author: |
|||
authors[reply.author.login] = reply.author |
|||
if reply.author.login != discussion_author_name: |
|||
author_time = discussion_commentors.get( |
|||
reply.author.login, reply.createdAt |
|||
) |
|||
discussion_commentors[reply.author.login] = max( |
|||
author_time, reply.createdAt |
|||
) |
|||
for author_name, author_time in discussion_commentors.items(): |
|||
commenters[author_name] += 1 |
|||
if author_time > one_month_ago: |
|||
last_month_commenters[author_name] += 1 |
|||
if author_time > three_months_ago: |
|||
three_months_commenters[author_name] += 1 |
|||
if author_time > six_months_ago: |
|||
six_months_commenters[author_name] += 1 |
|||
if author_time > one_year_ago: |
|||
one_year_commenters[author_name] += 1 |
|||
discussion_experts_results = DiscussionExpertsResults( |
|||
authors=authors, |
|||
commenters=commenters, |
|||
last_month_commenters=last_month_commenters, |
|||
three_months_commenters=three_months_commenters, |
|||
six_months_commenters=six_months_commenters, |
|||
one_year_commenters=one_year_commenters, |
|||
) |
|||
return discussion_experts_results |
|||
|
|||
|
|||
def get_pr_nodes(settings: Settings) -> List[PullRequestNode]: |
|||
pr_nodes: List[PullRequestNode] = [] |
|||
pr_edges = get_graphql_pr_edges(settings=settings) |
|||
|
|||
while pr_edges: |
|||
for edge in pr_edges: |
|||
pr_nodes.append(edge.node) |
|||
last_edge = pr_edges[-1] |
|||
pr_edges = get_graphql_pr_edges(settings=settings, after=last_edge.cursor) |
|||
return pr_nodes |
|||
|
|||
|
|||
class ContributorsResults(BaseModel): |
|||
contributors: Counter |
|||
commenters: Counter |
|||
reviewers: Counter |
|||
translation_reviewers: Counter |
|||
authors: Dict[str, Author] |
|||
|
|||
|
|||
def get_contributors(pr_nodes: List[PullRequestNode]) -> ContributorsResults: |
|||
contributors = Counter() |
|||
commenters = Counter() |
|||
reviewers = Counter() |
|||
translation_reviewers = Counter() |
|||
authors: Dict[str, Author] = {} |
|||
|
|||
for pr in pr_nodes: |
|||
author_name = None |
|||
if pr.author: |
|||
authors[pr.author.login] = pr.author |
|||
author_name = pr.author.login |
|||
pr_commentors: Set[str] = set() |
|||
pr_reviewers: Set[str] = set() |
|||
for comment in pr.comments.nodes: |
|||
if comment.author: |
|||
authors[comment.author.login] = comment.author |
|||
if comment.author.login == author_name: |
|||
continue |
|||
pr_commentors.add(comment.author.login) |
|||
for author_name in pr_commentors: |
|||
commenters[author_name] += 1 |
|||
for review in pr.reviews.nodes: |
|||
if review.author: |
|||
authors[review.author.login] = review.author |
|||
pr_reviewers.add(review.author.login) |
|||
for label in pr.labels.nodes: |
|||
if label.name == "lang-all": |
|||
translation_reviewers[review.author.login] += 1 |
|||
break |
|||
for reviewer in pr_reviewers: |
|||
reviewers[reviewer] += 1 |
|||
if pr.state == "MERGED" and pr.author: |
|||
contributors[pr.author.login] += 1 |
|||
return ContributorsResults( |
|||
contributors=contributors, |
|||
commenters=commenters, |
|||
reviewers=reviewers, |
|||
translation_reviewers=translation_reviewers, |
|||
authors=authors, |
|||
) |
|||
|
|||
|
|||
def get_individual_sponsors(settings: Settings): |
|||
nodes: List[SponsorshipAsMaintainerNode] = [] |
|||
edges = get_graphql_sponsor_edges(settings=settings) |
|||
|
|||
while edges: |
|||
for edge in edges: |
|||
nodes.append(edge.node) |
|||
last_edge = edges[-1] |
|||
edges = get_graphql_sponsor_edges(settings=settings, after=last_edge.cursor) |
|||
|
|||
tiers: DefaultDict[float, Dict[str, SponsorEntity]] = defaultdict(dict) |
|||
for node in nodes: |
|||
tiers[node.tier.monthlyPriceInDollars][node.sponsorEntity.login] = ( |
|||
node.sponsorEntity |
|||
) |
|||
return tiers |
|||
|
|||
|
|||
def get_top_users( |
|||
*, |
|||
counter: Counter, |
|||
authors: Dict[str, Author], |
|||
skip_users: Container[str], |
|||
min_count: int = 2, |
|||
): |
|||
users = [] |
|||
for commenter, count in counter.most_common(50): |
|||
if commenter in skip_users: |
|||
continue |
|||
if count >= min_count: |
|||
author = authors[commenter] |
|||
users.append( |
|||
{ |
|||
"login": commenter, |
|||
"count": count, |
|||
"avatarUrl": author.avatarUrl, |
|||
"url": author.url, |
|||
} |
|||
) |
|||
return users |
|||
|
|||
|
|||
if __name__ == "__main__": |
|||
logging.basicConfig(level=logging.INFO) |
|||
settings = Settings() |
|||
logging.info(f"Using config: {settings.model_dump_json()}") |
|||
g = Github(settings.input_token.get_secret_value()) |
|||
repo = g.get_repo(settings.github_repository) |
|||
discussion_nodes = get_discussion_nodes(settings=settings) |
|||
experts_results = get_discussions_experts(discussion_nodes=discussion_nodes) |
|||
pr_nodes = get_pr_nodes(settings=settings) |
|||
contributors_results = get_contributors(pr_nodes=pr_nodes) |
|||
authors = {**experts_results.authors, **contributors_results.authors} |
|||
maintainers_logins = {"tiangolo"} |
|||
bot_names = {"codecov", "github-actions", "pre-commit-ci", "dependabot"} |
|||
maintainers = [] |
|||
for login in maintainers_logins: |
|||
user = authors[login] |
|||
maintainers.append( |
|||
{ |
|||
"login": login, |
|||
"answers": experts_results.commenters[login], |
|||
"prs": contributors_results.contributors[login], |
|||
"avatarUrl": user.avatarUrl, |
|||
"url": user.url, |
|||
} |
|||
) |
|||
|
|||
skip_users = maintainers_logins | bot_names |
|||
experts = get_top_users( |
|||
counter=experts_results.commenters, |
|||
authors=authors, |
|||
skip_users=skip_users, |
|||
) |
|||
last_month_experts = get_top_users( |
|||
counter=experts_results.last_month_commenters, |
|||
authors=authors, |
|||
skip_users=skip_users, |
|||
) |
|||
three_months_experts = get_top_users( |
|||
counter=experts_results.three_months_commenters, |
|||
authors=authors, |
|||
skip_users=skip_users, |
|||
) |
|||
six_months_experts = get_top_users( |
|||
counter=experts_results.six_months_commenters, |
|||
authors=authors, |
|||
skip_users=skip_users, |
|||
) |
|||
one_year_experts = get_top_users( |
|||
counter=experts_results.one_year_commenters, |
|||
authors=authors, |
|||
skip_users=skip_users, |
|||
) |
|||
top_contributors = get_top_users( |
|||
counter=contributors_results.contributors, |
|||
authors=authors, |
|||
skip_users=skip_users, |
|||
) |
|||
top_reviewers = get_top_users( |
|||
counter=contributors_results.reviewers, |
|||
authors=authors, |
|||
skip_users=skip_users, |
|||
) |
|||
top_translations_reviewers = get_top_users( |
|||
counter=contributors_results.translation_reviewers, |
|||
authors=authors, |
|||
skip_users=skip_users, |
|||
) |
|||
|
|||
tiers = get_individual_sponsors(settings=settings) |
|||
keys = list(tiers.keys()) |
|||
keys.sort(reverse=True) |
|||
sponsors = [] |
|||
for key in keys: |
|||
sponsor_group = [] |
|||
for login, sponsor in tiers[key].items(): |
|||
sponsor_group.append( |
|||
{"login": login, "avatarUrl": sponsor.avatarUrl, "url": sponsor.url} |
|||
) |
|||
sponsors.append(sponsor_group) |
|||
|
|||
people = { |
|||
"maintainers": maintainers, |
|||
"experts": experts, |
|||
"last_month_experts": last_month_experts, |
|||
"three_months_experts": three_months_experts, |
|||
"six_months_experts": six_months_experts, |
|||
"one_year_experts": one_year_experts, |
|||
"top_contributors": top_contributors, |
|||
"top_reviewers": top_reviewers, |
|||
"top_translations_reviewers": top_translations_reviewers, |
|||
} |
|||
github_sponsors = { |
|||
"sponsors": sponsors, |
|||
} |
|||
# For local development |
|||
# people_path = Path("../../../../docs/en/data/people.yml") |
|||
people_path = Path("./docs/en/data/people.yml") |
|||
github_sponsors_path = Path("./docs/en/data/github_sponsors.yml") |
|||
people_old_content = people_path.read_text(encoding="utf-8") |
|||
github_sponsors_old_content = github_sponsors_path.read_text(encoding="utf-8") |
|||
new_people_content = yaml.dump( |
|||
people, sort_keys=False, width=200, allow_unicode=True |
|||
) |
|||
new_github_sponsors_content = yaml.dump( |
|||
github_sponsors, sort_keys=False, width=200, allow_unicode=True |
|||
) |
|||
if ( |
|||
people_old_content == new_people_content |
|||
and github_sponsors_old_content == new_github_sponsors_content |
|||
): |
|||
logging.info("The FastAPI People data hasn't changed, finishing.") |
|||
sys.exit(0) |
|||
people_path.write_text(new_people_content, encoding="utf-8") |
|||
github_sponsors_path.write_text(new_github_sponsors_content, encoding="utf-8") |
|||
logging.info("Setting up GitHub Actions git user") |
|||
subprocess.run(["git", "config", "user.name", "github-actions"], check=True) |
|||
subprocess.run( |
|||
["git", "config", "user.email", "[email protected]"], check=True |
|||
) |
|||
branch_name = "fastapi-people" |
|||
logging.info(f"Creating a new branch {branch_name}") |
|||
subprocess.run(["git", "checkout", "-b", branch_name], check=True) |
|||
logging.info("Adding updated file") |
|||
subprocess.run( |
|||
["git", "add", str(people_path), str(github_sponsors_path)], check=True |
|||
) |
|||
logging.info("Committing updated file") |
|||
message = "👥 Update FastAPI People" |
|||
result = subprocess.run(["git", "commit", "-m", message], check=True) |
|||
logging.info("Pushing branch") |
|||
subprocess.run(["git", "push", "origin", branch_name], check=True) |
|||
logging.info("Creating PR") |
|||
pr = repo.create_pull(title=message, body=message, base="master", head=branch_name) |
|||
logging.info(f"Created PR: {pr.number}") |
|||
logging.info("Finished") |
@ -0,0 +1,53 @@ |
|||
name: FastAPI People Contributors |
|||
|
|||
on: |
|||
schedule: |
|||
- cron: "0 3 1 * *" |
|||
workflow_dispatch: |
|||
inputs: |
|||
debug_enabled: |
|||
description: "Run the build with tmate debugging enabled (https://github.com/marketplace/actions/debugging-with-tmate)" |
|||
required: false |
|||
default: "false" |
|||
|
|||
env: |
|||
UV_SYSTEM_PYTHON: 1 |
|||
|
|||
jobs: |
|||
job: |
|||
if: github.repository_owner == 'fastapi' |
|||
runs-on: ubuntu-latest |
|||
permissions: |
|||
contents: write |
|||
steps: |
|||
- name: Dump GitHub context |
|||
env: |
|||
GITHUB_CONTEXT: ${{ toJson(github) }} |
|||
run: echo "$GITHUB_CONTEXT" |
|||
- uses: actions/checkout@v4 |
|||
- name: Set up Python |
|||
uses: actions/setup-python@v5 |
|||
with: |
|||
python-version: "3.11" |
|||
- name: Setup uv |
|||
uses: astral-sh/setup-uv@v5 |
|||
with: |
|||
version: "0.4.15" |
|||
enable-cache: true |
|||
cache-dependency-glob: | |
|||
requirements**.txt |
|||
pyproject.toml |
|||
- name: Install Dependencies |
|||
run: uv pip install -r requirements-github-actions.txt |
|||
# Allow debugging with tmate |
|||
- name: Setup tmate session |
|||
uses: mxschmitt/action-tmate@v3 |
|||
if: ${{ github.event_name == 'workflow_dispatch' && github.event.inputs.debug_enabled == 'true' }} |
|||
with: |
|||
limit-access-to-actor: true |
|||
env: |
|||
GITHUB_TOKEN: ${{ secrets.FASTAPI_PR_TOKEN }} |
|||
- name: FastAPI People Contributors |
|||
run: python ./scripts/contributors.py |
|||
env: |
|||
GITHUB_TOKEN: ${{ secrets.FASTAPI_PR_TOKEN }} |
@ -29,7 +29,7 @@ jobs: |
|||
with: |
|||
python-version: "3.11" |
|||
- name: Setup uv |
|||
uses: astral-sh/setup-uv@v4 |
|||
uses: astral-sh/setup-uv@v5 |
|||
with: |
|||
version: "0.4.15" |
|||
enable-cache: true |
|||
@ -62,10 +62,7 @@ jobs: |
|||
env: |
|||
PROJECT_NAME: fastapitiangolo |
|||
BRANCH: ${{ ( github.event.workflow_run.head_repository.full_name == github.repository && github.event.workflow_run.head_branch == 'master' && 'main' ) || ( github.event.workflow_run.head_sha ) }} |
|||
# TODO: Use v3 when it's fixed, probably in v3.11 |
|||
# https://github.com/cloudflare/wrangler-action/issues/307 |
|||
uses: cloudflare/[email protected] |
|||
# uses: cloudflare/wrangler-action@v3 |
|||
uses: cloudflare/wrangler-action@v3 |
|||
with: |
|||
apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }} |
|||
accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }} |
|||
|
@ -35,7 +35,7 @@ jobs: |
|||
TIANGOLO_BUILD_PACKAGE: ${{ matrix.package }} |
|||
run: python -m build |
|||
- name: Publish |
|||
uses: pypa/[email protected].3 |
|||
uses: pypa/[email protected].4 |
|||
- name: Dump GitHub context |
|||
env: |
|||
GITHUB_CONTEXT: ${{ toJson(github) }} |
|||
|
@ -0,0 +1,52 @@ |
|||
name: FastAPI People Sponsors |
|||
|
|||
on: |
|||
schedule: |
|||
- cron: "0 6 1 * *" |
|||
workflow_dispatch: |
|||
inputs: |
|||
debug_enabled: |
|||
description: "Run the build with tmate debugging enabled (https://github.com/marketplace/actions/debugging-with-tmate)" |
|||
required: false |
|||
default: "false" |
|||
|
|||
env: |
|||
UV_SYSTEM_PYTHON: 1 |
|||
|
|||
jobs: |
|||
job: |
|||
if: github.repository_owner == 'fastapi' |
|||
runs-on: ubuntu-latest |
|||
permissions: |
|||
contents: write |
|||
steps: |
|||
- name: Dump GitHub context |
|||
env: |
|||
GITHUB_CONTEXT: ${{ toJson(github) }} |
|||
run: echo "$GITHUB_CONTEXT" |
|||
- uses: actions/checkout@v4 |
|||
- name: Set up Python |
|||
uses: actions/setup-python@v5 |
|||
with: |
|||
python-version: "3.11" |
|||
- name: Setup uv |
|||
uses: astral-sh/setup-uv@v5 |
|||
with: |
|||
version: "0.4.15" |
|||
enable-cache: true |
|||
cache-dependency-glob: | |
|||
requirements**.txt |
|||
pyproject.toml |
|||
- name: Install Dependencies |
|||
run: uv pip install -r requirements-github-actions.txt |
|||
# Allow debugging with tmate |
|||
- name: Setup tmate session |
|||
uses: mxschmitt/action-tmate@v3 |
|||
if: ${{ github.event_name == 'workflow_dispatch' && github.event.inputs.debug_enabled == 'true' }} |
|||
with: |
|||
limit-access-to-actor: true |
|||
- name: FastAPI People Sponsors |
|||
run: python ./scripts/sponsors.py |
|||
env: |
|||
SPONSORS_TOKEN: ${{ secrets.SPONSORS_TOKEN }} |
|||
PR_TOKEN: ${{ secrets.FASTAPI_PR_TOKEN }} |
@ -0,0 +1,40 @@ |
|||
name: Update Topic Repos |
|||
|
|||
on: |
|||
schedule: |
|||
- cron: "0 12 1 * *" |
|||
workflow_dispatch: |
|||
|
|||
env: |
|||
UV_SYSTEM_PYTHON: 1 |
|||
|
|||
jobs: |
|||
topic-repos: |
|||
if: github.repository_owner == 'fastapi' |
|||
runs-on: ubuntu-latest |
|||
permissions: |
|||
contents: write |
|||
steps: |
|||
- name: Dump GitHub context |
|||
env: |
|||
GITHUB_CONTEXT: ${{ toJson(github) }} |
|||
run: echo "$GITHUB_CONTEXT" |
|||
- uses: actions/checkout@v4 |
|||
- name: Set up Python |
|||
uses: actions/setup-python@v5 |
|||
with: |
|||
python-version: "3.11" |
|||
- name: Setup uv |
|||
uses: astral-sh/setup-uv@v5 |
|||
with: |
|||
version: "0.4.15" |
|||
enable-cache: true |
|||
cache-dependency-glob: | |
|||
requirements**.txt |
|||
pyproject.toml |
|||
- name: Install GitHub Actions dependencies |
|||
run: uv pip install -r requirements-github-actions.txt |
|||
- name: Update Topic Repos |
|||
run: python ./scripts/topic_repos.py |
|||
env: |
|||
GITHUB_TOKEN: ${{ secrets.FASTAPI_PR_TOKEN }} |
@ -0,0 +1,520 @@ |
|||
tiangolo: |
|||
login: tiangolo |
|||
count: 713 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/1326112?u=cb5d06e73a9e1998141b1641aa88e443c6717651&v=4 |
|||
url: https://github.com/tiangolo |
|||
dependabot: |
|||
login: dependabot |
|||
count: 90 |
|||
avatarUrl: https://avatars.githubusercontent.com/in/29110?v=4 |
|||
url: https://github.com/apps/dependabot |
|||
alejsdev: |
|||
login: alejsdev |
|||
count: 47 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/90076947?u=356f39ff3f0211c720b06d3dbb060e98884085e3&v=4 |
|||
url: https://github.com/alejsdev |
|||
github-actions: |
|||
login: github-actions |
|||
count: 26 |
|||
avatarUrl: https://avatars.githubusercontent.com/in/15368?v=4 |
|||
url: https://github.com/apps/github-actions |
|||
Kludex: |
|||
login: Kludex |
|||
count: 23 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/7353520?u=df8a3f06ba8f55ae1967a3e2d5ed882903a4e330&v=4 |
|||
url: https://github.com/Kludex |
|||
pre-commit-ci: |
|||
login: pre-commit-ci |
|||
count: 22 |
|||
avatarUrl: https://avatars.githubusercontent.com/in/68672?v=4 |
|||
url: https://github.com/apps/pre-commit-ci |
|||
dmontagu: |
|||
login: dmontagu |
|||
count: 17 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/35119617?u=540f30c937a6450812628b9592a1dfe91bbe148e&v=4 |
|||
url: https://github.com/dmontagu |
|||
euri10: |
|||
login: euri10 |
|||
count: 13 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/1104190?u=321a2e953e6645a7d09b732786c7a8061e0f8a8b&v=4 |
|||
url: https://github.com/euri10 |
|||
kantandane: |
|||
login: kantandane |
|||
count: 13 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/3978368?u=cccc199291f991a73b1ebba5abc735a948e0bd16&v=4 |
|||
url: https://github.com/kantandane |
|||
nilslindemann: |
|||
login: nilslindemann |
|||
count: 11 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/6892179?u=1dca6a22195d6cd1ab20737c0e19a4c55d639472&v=4 |
|||
url: https://github.com/nilslindemann |
|||
zhaohan-dong: |
|||
login: zhaohan-dong |
|||
count: 11 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/65422392?u=8260f8781f50248410ebfa4c9bf70e143fe5c9f2&v=4 |
|||
url: https://github.com/zhaohan-dong |
|||
mariacamilagl: |
|||
login: mariacamilagl |
|||
count: 9 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/11489395?u=4adb6986bf3debfc2b8216ae701f2bd47d73da7d&v=4 |
|||
url: https://github.com/mariacamilagl |
|||
handabaldeep: |
|||
login: handabaldeep |
|||
count: 9 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/12239103?u=6c39ef15d14c6d5211f5dd775cc4842f8d7f2f3a&v=4 |
|||
url: https://github.com/handabaldeep |
|||
vishnuvskvkl: |
|||
login: vishnuvskvkl |
|||
count: 8 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/84698110?u=8af5de0520dd4fa195f53c2850a26f57c0f6bc64&v=4 |
|||
url: https://github.com/vishnuvskvkl |
|||
alissadb: |
|||
login: alissadb |
|||
count: 6 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/96190409?u=be42d85938c241be781505a5a872575be28b2906&v=4 |
|||
url: https://github.com/alissadb |
|||
wshayes: |
|||
login: wshayes |
|||
count: 5 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/365303?u=07ca03c5ee811eb0920e633cc3c3db73dbec1aa5&v=4 |
|||
url: https://github.com/wshayes |
|||
samuelcolvin: |
|||
login: samuelcolvin |
|||
count: 5 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/4039449?u=42eb3b833047c8c4b4f647a031eaef148c16d93f&v=4 |
|||
url: https://github.com/samuelcolvin |
|||
waynerv: |
|||
login: waynerv |
|||
count: 5 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/39515546?u=ec35139777597cdbbbddda29bf8b9d4396b429a9&v=4 |
|||
url: https://github.com/waynerv |
|||
svlandeg: |
|||
login: svlandeg |
|||
count: 5 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/8796347?u=556c97650c27021911b0b9447ec55e75987b0e8a&v=4 |
|||
url: https://github.com/svlandeg |
|||
krishnamadhavan: |
|||
login: krishnamadhavan |
|||
count: 5 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/31798870?u=950693b28f3ae01105fd545c046e46ca3d31ab06&v=4 |
|||
url: https://github.com/krishnamadhavan |
|||
jekirl: |
|||
login: jekirl |
|||
count: 4 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/2546697?u=a027452387d85bd4a14834e19d716c99255fb3b7&v=4 |
|||
url: https://github.com/jekirl |
|||
hitrust: |
|||
login: hitrust |
|||
count: 4 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/3360631?u=5fa1f475ad784d64eb9666bdd43cc4d285dcc773&v=4 |
|||
url: https://github.com/hitrust |
|||
ShahriyarR: |
|||
login: ShahriyarR |
|||
count: 4 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/3852029?u=c9a1691e5ebdc94cbf543086099a6ed705cdb873&v=4 |
|||
url: https://github.com/ShahriyarR |
|||
adriangb: |
|||
login: adriangb |
|||
count: 4 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/1755071?u=612704256e38d6ac9cbed24f10e4b6ac2da74ecb&v=4 |
|||
url: https://github.com/adriangb |
|||
iudeen: |
|||
login: iudeen |
|||
count: 4 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/10519440?u=2843b3303282bff8b212dcd4d9d6689452e4470c&v=4 |
|||
url: https://github.com/iudeen |
|||
philipokiokio: |
|||
login: philipokiokio |
|||
count: 4 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/55271518?u=d30994d339aaaf1f6bf1b8fc810132016fbd4fdc&v=4 |
|||
url: https://github.com/philipokiokio |
|||
AlexWendland: |
|||
login: AlexWendland |
|||
count: 4 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/3949212?u=c4c0c615e0ea33d00bfe16b779cf6ebc0f58071c&v=4 |
|||
url: https://github.com/AlexWendland |
|||
divums: |
|||
login: divums |
|||
count: 3 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/1397556?v=4 |
|||
url: https://github.com/divums |
|||
prostomarkeloff: |
|||
login: prostomarkeloff |
|||
count: 3 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/28061158?u=6918e39a1224194ba636e897461a02a20126d7ad&v=4 |
|||
url: https://github.com/prostomarkeloff |
|||
nsidnev: |
|||
login: nsidnev |
|||
count: 3 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/22559461?u=a9cc3238217e21dc8796a1a500f01b722adb082c&v=4 |
|||
url: https://github.com/nsidnev |
|||
pawamoy: |
|||
login: pawamoy |
|||
count: 3 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/3999221?u=b030e4c89df2f3a36bc4710b925bdeb6745c9856&v=4 |
|||
url: https://github.com/pawamoy |
|||
patrickmckenna: |
|||
login: patrickmckenna |
|||
count: 3 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/3589536?u=53aef07250d226d35e526768e26891964907b41a&v=4 |
|||
url: https://github.com/patrickmckenna |
|||
hukkin: |
|||
login: hukkin |
|||
count: 3 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/3275109?u=77bb83759127965eacbfe67e2ca983066e964fde&v=4 |
|||
url: https://github.com/hukkin |
|||
marcosmmb: |
|||
login: marcosmmb |
|||
count: 3 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/6181089?u=b8567a842b38c5570c315b2b7ca766fa7be6721e&v=4 |
|||
url: https://github.com/marcosmmb |
|||
Serrones: |
|||
login: Serrones |
|||
count: 3 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/22691749?u=4795b880e13ca33a73e52fc0ef7dc9c60c8fce47&v=4 |
|||
url: https://github.com/Serrones |
|||
uriyyo: |
|||
login: uriyyo |
|||
count: 3 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/32038156?u=a27b65a9ec3420586a827a0facccbb8b6df1ffb3&v=4 |
|||
url: https://github.com/uriyyo |
|||
amacfie: |
|||
login: amacfie |
|||
count: 3 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/889657?u=d70187989940b085bcbfa3bedad8dbc5f3ab1fe7&v=4 |
|||
url: https://github.com/amacfie |
|||
rkbeatss: |
|||
login: rkbeatss |
|||
count: 3 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/23391143?u=56ab6bff50be950fa8cae5cf736f2ae66e319ff3&v=4 |
|||
url: https://github.com/rkbeatss |
|||
asheux: |
|||
login: asheux |
|||
count: 3 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/22955146?u=4553ebf5b5a7c7fe031a46182083aa224faba2e1&v=4 |
|||
url: https://github.com/asheux |
|||
n25a: |
|||
login: n25a |
|||
count: 3 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/49960770?u=7d8a6d5f0a75a5e9a865a2527edfd48895ea27ae&v=4 |
|||
url: https://github.com/n25a |
|||
ghandic: |
|||
login: ghandic |
|||
count: 3 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/23500353?u=e2e1d736f924d9be81e8bfc565b6d8836ba99773&v=4 |
|||
url: https://github.com/ghandic |
|||
TeoZosa: |
|||
login: TeoZosa |
|||
count: 3 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/13070236?u=96fdae85800ef85dcfcc4b5f8281dc8778c8cb7d&v=4 |
|||
url: https://github.com/TeoZosa |
|||
graingert: |
|||
login: graingert |
|||
count: 3 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/413772?u=64b77b6aa405c68a9c6bcf45f84257c66eea5f32&v=4 |
|||
url: https://github.com/graingert |
|||
jaystone776: |
|||
login: jaystone776 |
|||
count: 3 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/11191137?u=299205a95e9b6817a43144a48b643346a5aac5cc&v=4 |
|||
url: https://github.com/jaystone776 |
|||
zanieb: |
|||
login: zanieb |
|||
count: 3 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/2586601?u=e5c86f7ff3b859e7e183187ac2b17fd6ee32b3ab&v=4 |
|||
url: https://github.com/zanieb |
|||
MicaelJarniac: |
|||
login: MicaelJarniac |
|||
count: 3 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/19514231?u=158c91874ea98d6e9e6f0c6db37ee2ce60c55ff2&v=4 |
|||
url: https://github.com/MicaelJarniac |
|||
papb: |
|||
login: papb |
|||
count: 3 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/20914054?u=890511fae7ea90d887e2a65ce44a1775abba38d5&v=4 |
|||
url: https://github.com/papb |
|||
gitworkflows: |
|||
login: gitworkflows |
|||
count: 3 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/118260833?v=4 |
|||
url: https://github.com/gitworkflows |
|||
Nimitha-jagadeesha: |
|||
login: Nimitha-jagadeesha |
|||
count: 3 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/58389915?v=4 |
|||
url: https://github.com/Nimitha-jagadeesha |
|||
lucaromagnoli: |
|||
login: lucaromagnoli |
|||
count: 3 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/38782977?u=e66396859f493b4ddcb3a837a1b2b2039c805417&v=4 |
|||
url: https://github.com/lucaromagnoli |
|||
salmantec: |
|||
login: salmantec |
|||
count: 3 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/41512228?u=443551b893ff2425c59d5d021644f098cf7c68d5&v=4 |
|||
url: https://github.com/salmantec |
|||
OCE1960: |
|||
login: OCE1960 |
|||
count: 3 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/45076670?u=0e9a44712b92ffa89ddfbaa83c112f3f8e1d68e2&v=4 |
|||
url: https://github.com/OCE1960 |
|||
hamidrasti: |
|||
login: hamidrasti |
|||
count: 3 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/43915620?v=4 |
|||
url: https://github.com/hamidrasti |
|||
kkinder: |
|||
login: kkinder |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/1115018?u=c5e90284a9f5c5049eae1bb029e3655c7dc913ed&v=4 |
|||
url: https://github.com/kkinder |
|||
kabirkhan: |
|||
login: kabirkhan |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/13891834?u=e0eabf792376443ac853e7dca6f550db4166fe35&v=4 |
|||
url: https://github.com/kabirkhan |
|||
zamiramir: |
|||
login: zamiramir |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/40475662?u=e58ef61034e8d0d6a312cc956fb09b9c3332b449&v=4 |
|||
url: https://github.com/zamiramir |
|||
trim21: |
|||
login: trim21 |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/13553903?u=3cadf0f02095c9621aa29df6875f53a80ca4fbfb&v=4 |
|||
url: https://github.com/trim21 |
|||
koxudaxi: |
|||
login: koxudaxi |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/630670?u=507d8577b4b3670546b449c4c2ccbc5af40d72f7&v=4 |
|||
url: https://github.com/koxudaxi |
|||
pablogamboa: |
|||
login: pablogamboa |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/12892536?u=326a57059ee0c40c4eb1b38413957236841c631b&v=4 |
|||
url: https://github.com/pablogamboa |
|||
dconathan: |
|||
login: dconathan |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/15098095?v=4 |
|||
url: https://github.com/dconathan |
|||
Jamim: |
|||
login: Jamim |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/5607572?u=0cf3027bec78ba4f0b89802430c136bc69847d7a&v=4 |
|||
url: https://github.com/Jamim |
|||
svalouch: |
|||
login: svalouch |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/54674660?v=4 |
|||
url: https://github.com/svalouch |
|||
frankie567: |
|||
login: frankie567 |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/1144727?u=c159fe047727aedecbbeeaa96a1b03ceb9d39add&v=4 |
|||
url: https://github.com/frankie567 |
|||
marier-nico: |
|||
login: marier-nico |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/30477068?u=c7df6af853c8f4163d1517814f3e9a0715c82713&v=4 |
|||
url: https://github.com/marier-nico |
|||
Dustyposa: |
|||
login: Dustyposa |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/27180793?u=5cf2877f50b3eb2bc55086089a78a36f07042889&v=4 |
|||
url: https://github.com/Dustyposa |
|||
aviramha: |
|||
login: aviramha |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/41201924?u=6883cc4fc13a7b2e60d4deddd4be06f9c5287880&v=4 |
|||
url: https://github.com/aviramha |
|||
iwpnd: |
|||
login: iwpnd |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/6152183?u=ec59396e9437fff488791c5ecdf6d23f1f1ebf3a&v=4 |
|||
url: https://github.com/iwpnd |
|||
raphaelauv: |
|||
login: raphaelauv |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/10202690?u=e6f86f5c0c3026a15d6b51792fa3e532b12f1371&v=4 |
|||
url: https://github.com/raphaelauv |
|||
windson: |
|||
login: windson |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/1826682?u=8b28dcd716c46289f191f8828e01d74edd058bef&v=4 |
|||
url: https://github.com/windson |
|||
sm-Fifteen: |
|||
login: sm-Fifteen |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/516999?u=437c0c5038558c67e887ccd863c1ba0f846c03da&v=4 |
|||
url: https://github.com/sm-Fifteen |
|||
sattosan: |
|||
login: sattosan |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/20574756?u=b0d8474d2938189c6954423ae8d81d91013f80a8&v=4 |
|||
url: https://github.com/sattosan |
|||
michaeloliverx: |
|||
login: michaeloliverx |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/55017335?u=e606eb5cc397c07523be47637b1ee796904fbb59&v=4 |
|||
url: https://github.com/michaeloliverx |
|||
voegtlel: |
|||
login: voegtlel |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/5764745?u=db8df3d70d427928ab6d7dbfc395a4a7109c1d1b&v=4 |
|||
url: https://github.com/voegtlel |
|||
HarshaLaxman: |
|||
login: HarshaLaxman |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/19939186?u=a112f38b0f6b4d4402dc8b51978b5a0b2e5c5970&v=4 |
|||
url: https://github.com/HarshaLaxman |
|||
RunningIkkyu: |
|||
login: RunningIkkyu |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/31848542?u=494ecc298e3f26197495bb357ad0f57cfd5f7a32&v=4 |
|||
url: https://github.com/RunningIkkyu |
|||
cassiobotaro: |
|||
login: cassiobotaro |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/3127847?u=a08022b191ddbd0a6159b2981d9d878b6d5bb71f&v=4 |
|||
url: https://github.com/cassiobotaro |
|||
chenl: |
|||
login: chenl |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/1677651?u=c618508eaad6d596cea36c8ea784b424288f6857&v=4 |
|||
url: https://github.com/chenl |
|||
retnikt: |
|||
login: retnikt |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/24581770?v=4 |
|||
url: https://github.com/retnikt |
|||
yankeexe: |
|||
login: yankeexe |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/13623913?u=f970e66421775a8d3cdab89c0c752eaead186f6d&v=4 |
|||
url: https://github.com/yankeexe |
|||
patrickkwang: |
|||
login: patrickkwang |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/1263870?u=4bf74020e15be490f19ef8322a76eec882220b96&v=4 |
|||
url: https://github.com/patrickkwang |
|||
victorphoenix3: |
|||
login: victorphoenix3 |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/48182195?u=e4875bd088623cb4ddeb7be194ec54b453aff035&v=4 |
|||
url: https://github.com/victorphoenix3 |
|||
davidefiocco: |
|||
login: davidefiocco |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/4547987?v=4 |
|||
url: https://github.com/davidefiocco |
|||
adriencaccia: |
|||
login: adriencaccia |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/19605940?u=980b0b366a02791a5600b2e9f9ac2037679acaa8&v=4 |
|||
url: https://github.com/adriencaccia |
|||
jamescurtin: |
|||
login: jamescurtin |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/10189269?u=0b491fc600ca51f41cf1d95b49fa32a3eba1de57&v=4 |
|||
url: https://github.com/jamescurtin |
|||
jmriebold: |
|||
login: jmriebold |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/6983392?u=4efdc97bf2422dcc7e9ff65b9ff80087c8eb2a20&v=4 |
|||
url: https://github.com/jmriebold |
|||
nukopy: |
|||
login: nukopy |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/42367320?u=6061be0bd060506f6d564a8df3ae73fab048cdfe&v=4 |
|||
url: https://github.com/nukopy |
|||
imba-tjd: |
|||
login: imba-tjd |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/24759802?u=01e901a4fe004b4b126549d3ff1c4000fe3720b5&v=4 |
|||
url: https://github.com/imba-tjd |
|||
johnthagen: |
|||
login: johnthagen |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/10340167?u=47147fc4e4db1f573bee3fe428deeacb3197bc5f&v=4 |
|||
url: https://github.com/johnthagen |
|||
paxcodes: |
|||
login: paxcodes |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/13646646?u=e7429cc7ab11211ef762f4cd3efea7db6d9ef036&v=4 |
|||
url: https://github.com/paxcodes |
|||
kaustubhgupta: |
|||
login: kaustubhgupta |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/43691873?u=8dd738718ac7ffad4ef31e86b5d780a1141c695d&v=4 |
|||
url: https://github.com/kaustubhgupta |
|||
kinuax: |
|||
login: kinuax |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/13321374?u=22dc9873d6d9f2c7e4fc44c6480c3505efb1531f&v=4 |
|||
url: https://github.com/kinuax |
|||
wakabame: |
|||
login: wakabame |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/35513518?u=41ef6b0a55076e5c540620d68fb006e386c2ddb0&v=4 |
|||
url: https://github.com/wakabame |
|||
nzig: |
|||
login: nzig |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/7372858?u=e769add36ed73c778cdb136eb10bf96b1e119671&v=4 |
|||
url: https://github.com/nzig |
|||
yezz123: |
|||
login: yezz123 |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/52716203?u=d7062cbc6eb7671d5dc9cc0e32a24ae335e0f225&v=4 |
|||
url: https://github.com/yezz123 |
|||
musicinmybrain: |
|||
login: musicinmybrain |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/6898909?u=9010312053e7141383b9bdf538036c7f37fbaba0&v=4 |
|||
url: https://github.com/musicinmybrain |
|||
softwarebloat: |
|||
login: softwarebloat |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/16540684?v=4 |
|||
url: https://github.com/softwarebloat |
|||
Lancetnik: |
|||
login: Lancetnik |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/44573917?u=f9a18be7324333daf9cc314c35c3051f0a20a7a6&v=4 |
|||
url: https://github.com/Lancetnik |
|||
yogabonito: |
|||
login: yogabonito |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/7026269?v=4 |
|||
url: https://github.com/yogabonito |
|||
s111d: |
|||
login: s111d |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/4954856?v=4 |
|||
url: https://github.com/s111d |
|||
estebanx64: |
|||
login: estebanx64 |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/10840422?u=45f015f95e1c0f06df602be4ab688d4b854cc8a8&v=4 |
|||
url: https://github.com/estebanx64 |
|||
tamird: |
|||
login: tamird |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/1535036?v=4 |
|||
url: https://github.com/tamird |
|||
rabinlamadong: |
|||
login: rabinlamadong |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/170439781?v=4 |
|||
url: https://github.com/rabinlamadong |
|||
AyushSinghal1794: |
|||
login: AyushSinghal1794 |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/89984761?v=4 |
|||
url: https://github.com/AyushSinghal1794 |
|||
DanielKusyDev: |
|||
login: DanielKusyDev |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/36250676?u=2ea6114ff751fc48b55f231987a0e2582c6b1bd2&v=4 |
|||
url: https://github.com/DanielKusyDev |
@ -0,0 +1,5 @@ |
|||
- tiangolo |
|||
- codecov |
|||
- github-actions |
|||
- pre-commit-ci |
|||
- dependabot |
@ -0,0 +1,495 @@ |
|||
- name: full-stack-fastapi-template |
|||
html_url: https://github.com/fastapi/full-stack-fastapi-template |
|||
stars: 29409 |
|||
owner_login: fastapi |
|||
owner_html_url: https://github.com/fastapi |
|||
- name: Hello-Python |
|||
html_url: https://github.com/mouredev/Hello-Python |
|||
stars: 28113 |
|||
owner_login: mouredev |
|||
owner_html_url: https://github.com/mouredev |
|||
- name: serve |
|||
html_url: https://github.com/jina-ai/serve |
|||
stars: 21264 |
|||
owner_login: jina-ai |
|||
owner_html_url: https://github.com/jina-ai |
|||
- name: sqlmodel |
|||
html_url: https://github.com/fastapi/sqlmodel |
|||
stars: 15109 |
|||
owner_login: fastapi |
|||
owner_html_url: https://github.com/fastapi |
|||
- name: HivisionIDPhotos |
|||
html_url: https://github.com/Zeyi-Lin/HivisionIDPhotos |
|||
stars: 14564 |
|||
owner_login: Zeyi-Lin |
|||
owner_html_url: https://github.com/Zeyi-Lin |
|||
- name: Douyin_TikTok_Download_API |
|||
html_url: https://github.com/Evil0ctal/Douyin_TikTok_Download_API |
|||
stars: 10701 |
|||
owner_login: Evil0ctal |
|||
owner_html_url: https://github.com/Evil0ctal |
|||
- name: fastapi-best-practices |
|||
html_url: https://github.com/zhanymkanov/fastapi-best-practices |
|||
stars: 10180 |
|||
owner_login: zhanymkanov |
|||
owner_html_url: https://github.com/zhanymkanov |
|||
- name: awesome-fastapi |
|||
html_url: https://github.com/mjhea0/awesome-fastapi |
|||
stars: 9061 |
|||
owner_login: mjhea0 |
|||
owner_html_url: https://github.com/mjhea0 |
|||
- name: FastUI |
|||
html_url: https://github.com/pydantic/FastUI |
|||
stars: 8644 |
|||
owner_login: pydantic |
|||
owner_html_url: https://github.com/pydantic |
|||
- name: nonebot2 |
|||
html_url: https://github.com/nonebot/nonebot2 |
|||
stars: 6312 |
|||
owner_login: nonebot |
|||
owner_html_url: https://github.com/nonebot |
|||
- name: serge |
|||
html_url: https://github.com/serge-chat/serge |
|||
stars: 5686 |
|||
owner_login: serge-chat |
|||
owner_html_url: https://github.com/serge-chat |
|||
- name: FileCodeBox |
|||
html_url: https://github.com/vastsa/FileCodeBox |
|||
stars: 4933 |
|||
owner_login: vastsa |
|||
owner_html_url: https://github.com/vastsa |
|||
- name: fastapi-users |
|||
html_url: https://github.com/fastapi-users/fastapi-users |
|||
stars: 4849 |
|||
owner_login: fastapi-users |
|||
owner_html_url: https://github.com/fastapi-users |
|||
- name: hatchet |
|||
html_url: https://github.com/hatchet-dev/hatchet |
|||
stars: 4514 |
|||
owner_login: hatchet-dev |
|||
owner_html_url: https://github.com/hatchet-dev |
|||
- name: chatgpt-web-share |
|||
html_url: https://github.com/chatpire/chatgpt-web-share |
|||
stars: 4319 |
|||
owner_login: chatpire |
|||
owner_html_url: https://github.com/chatpire |
|||
- name: polar |
|||
html_url: https://github.com/polarsource/polar |
|||
stars: 4216 |
|||
owner_login: polarsource |
|||
owner_html_url: https://github.com/polarsource |
|||
- name: strawberry |
|||
html_url: https://github.com/strawberry-graphql/strawberry |
|||
stars: 4126 |
|||
owner_login: strawberry-graphql |
|||
owner_html_url: https://github.com/strawberry-graphql |
|||
- name: atrilabs-engine |
|||
html_url: https://github.com/Atri-Labs/atrilabs-engine |
|||
stars: 4114 |
|||
owner_login: Atri-Labs |
|||
owner_html_url: https://github.com/Atri-Labs |
|||
- name: dynaconf |
|||
html_url: https://github.com/dynaconf/dynaconf |
|||
stars: 3874 |
|||
owner_login: dynaconf |
|||
owner_html_url: https://github.com/dynaconf |
|||
- name: poem |
|||
html_url: https://github.com/poem-web/poem |
|||
stars: 3746 |
|||
owner_login: poem-web |
|||
owner_html_url: https://github.com/poem-web |
|||
- name: opyrator |
|||
html_url: https://github.com/ml-tooling/opyrator |
|||
stars: 3117 |
|||
owner_login: ml-tooling |
|||
owner_html_url: https://github.com/ml-tooling |
|||
- name: farfalle |
|||
html_url: https://github.com/rashadphz/farfalle |
|||
stars: 3094 |
|||
owner_login: rashadphz |
|||
owner_html_url: https://github.com/rashadphz |
|||
- name: fastapi-admin |
|||
html_url: https://github.com/fastapi-admin/fastapi-admin |
|||
stars: 3040 |
|||
owner_login: fastapi-admin |
|||
owner_html_url: https://github.com/fastapi-admin |
|||
- name: docarray |
|||
html_url: https://github.com/docarray/docarray |
|||
stars: 3007 |
|||
owner_login: docarray |
|||
owner_html_url: https://github.com/docarray |
|||
- name: datamodel-code-generator |
|||
html_url: https://github.com/koxudaxi/datamodel-code-generator |
|||
stars: 2914 |
|||
owner_login: koxudaxi |
|||
owner_html_url: https://github.com/koxudaxi |
|||
- name: fastapi-realworld-example-app |
|||
html_url: https://github.com/nsidnev/fastapi-realworld-example-app |
|||
stars: 2840 |
|||
owner_login: nsidnev |
|||
owner_html_url: https://github.com/nsidnev |
|||
- name: LitServe |
|||
html_url: https://github.com/Lightning-AI/LitServe |
|||
stars: 2804 |
|||
owner_login: Lightning-AI |
|||
owner_html_url: https://github.com/Lightning-AI |
|||
- name: uvicorn-gunicorn-fastapi-docker |
|||
html_url: https://github.com/tiangolo/uvicorn-gunicorn-fastapi-docker |
|||
stars: 2730 |
|||
owner_login: tiangolo |
|||
owner_html_url: https://github.com/tiangolo |
|||
- name: logfire |
|||
html_url: https://github.com/pydantic/logfire |
|||
stars: 2620 |
|||
owner_login: pydantic |
|||
owner_html_url: https://github.com/pydantic |
|||
- name: huma |
|||
html_url: https://github.com/danielgtaylor/huma |
|||
stars: 2567 |
|||
owner_login: danielgtaylor |
|||
owner_html_url: https://github.com/danielgtaylor |
|||
- name: tracecat |
|||
html_url: https://github.com/TracecatHQ/tracecat |
|||
stars: 2494 |
|||
owner_login: TracecatHQ |
|||
owner_html_url: https://github.com/TracecatHQ |
|||
- name: best-of-web-python |
|||
html_url: https://github.com/ml-tooling/best-of-web-python |
|||
stars: 2433 |
|||
owner_login: ml-tooling |
|||
owner_html_url: https://github.com/ml-tooling |
|||
- name: RasaGPT |
|||
html_url: https://github.com/paulpierre/RasaGPT |
|||
stars: 2386 |
|||
owner_login: paulpierre |
|||
owner_html_url: https://github.com/paulpierre |
|||
- name: fastapi-react |
|||
html_url: https://github.com/Buuntu/fastapi-react |
|||
stars: 2293 |
|||
owner_login: Buuntu |
|||
owner_html_url: https://github.com/Buuntu |
|||
- name: nextpy |
|||
html_url: https://github.com/dot-agent/nextpy |
|||
stars: 2256 |
|||
owner_login: dot-agent |
|||
owner_html_url: https://github.com/dot-agent |
|||
- name: 30-Days-of-Python |
|||
html_url: https://github.com/codingforentrepreneurs/30-Days-of-Python |
|||
stars: 2155 |
|||
owner_login: codingforentrepreneurs |
|||
owner_html_url: https://github.com/codingforentrepreneurs |
|||
- name: FastAPI-template |
|||
html_url: https://github.com/s3rius/FastAPI-template |
|||
stars: 2121 |
|||
owner_login: s3rius |
|||
owner_html_url: https://github.com/s3rius |
|||
- name: sqladmin |
|||
html_url: https://github.com/aminalaee/sqladmin |
|||
stars: 2021 |
|||
owner_login: aminalaee |
|||
owner_html_url: https://github.com/aminalaee |
|||
- name: langserve |
|||
html_url: https://github.com/langchain-ai/langserve |
|||
stars: 2006 |
|||
owner_login: langchain-ai |
|||
owner_html_url: https://github.com/langchain-ai |
|||
- name: fastapi-utils |
|||
html_url: https://github.com/fastapiutils/fastapi-utils |
|||
stars: 2002 |
|||
owner_login: fastapiutils |
|||
owner_html_url: https://github.com/fastapiutils |
|||
- name: solara |
|||
html_url: https://github.com/widgetti/solara |
|||
stars: 1967 |
|||
owner_login: widgetti |
|||
owner_html_url: https://github.com/widgetti |
|||
- name: supabase-py |
|||
html_url: https://github.com/supabase/supabase-py |
|||
stars: 1848 |
|||
owner_login: supabase |
|||
owner_html_url: https://github.com/supabase |
|||
- name: python-week-2022 |
|||
html_url: https://github.com/rochacbruno/python-week-2022 |
|||
stars: 1832 |
|||
owner_login: rochacbruno |
|||
owner_html_url: https://github.com/rochacbruno |
|||
- name: mangum |
|||
html_url: https://github.com/Kludex/mangum |
|||
stars: 1789 |
|||
owner_login: Kludex |
|||
owner_html_url: https://github.com/Kludex |
|||
- name: manage-fastapi |
|||
html_url: https://github.com/ycd/manage-fastapi |
|||
stars: 1711 |
|||
owner_login: ycd |
|||
owner_html_url: https://github.com/ycd |
|||
- name: ormar |
|||
html_url: https://github.com/collerek/ormar |
|||
stars: 1701 |
|||
owner_login: collerek |
|||
owner_html_url: https://github.com/collerek |
|||
- name: agentkit |
|||
html_url: https://github.com/BCG-X-Official/agentkit |
|||
stars: 1630 |
|||
owner_login: BCG-X-Official |
|||
owner_html_url: https://github.com/BCG-X-Official |
|||
- name: langchain-serve |
|||
html_url: https://github.com/jina-ai/langchain-serve |
|||
stars: 1617 |
|||
owner_login: jina-ai |
|||
owner_html_url: https://github.com/jina-ai |
|||
- name: termpair |
|||
html_url: https://github.com/cs01/termpair |
|||
stars: 1612 |
|||
owner_login: cs01 |
|||
owner_html_url: https://github.com/cs01 |
|||
- name: coronavirus-tracker-api |
|||
html_url: https://github.com/ExpDev07/coronavirus-tracker-api |
|||
stars: 1590 |
|||
owner_login: ExpDev07 |
|||
owner_html_url: https://github.com/ExpDev07 |
|||
- name: piccolo |
|||
html_url: https://github.com/piccolo-orm/piccolo |
|||
stars: 1519 |
|||
owner_login: piccolo-orm |
|||
owner_html_url: https://github.com/piccolo-orm |
|||
- name: fastapi-crudrouter |
|||
html_url: https://github.com/awtkns/fastapi-crudrouter |
|||
stars: 1449 |
|||
owner_login: awtkns |
|||
owner_html_url: https://github.com/awtkns |
|||
- name: fastapi-cache |
|||
html_url: https://github.com/long2ice/fastapi-cache |
|||
stars: 1447 |
|||
owner_login: long2ice |
|||
owner_html_url: https://github.com/long2ice |
|||
- name: openapi-python-client |
|||
html_url: https://github.com/openapi-generators/openapi-python-client |
|||
stars: 1434 |
|||
owner_login: openapi-generators |
|||
owner_html_url: https://github.com/openapi-generators |
|||
- name: awesome-fastapi-projects |
|||
html_url: https://github.com/Kludex/awesome-fastapi-projects |
|||
stars: 1398 |
|||
owner_login: Kludex |
|||
owner_html_url: https://github.com/Kludex |
|||
- name: awesome-python-resources |
|||
html_url: https://github.com/DjangoEx/awesome-python-resources |
|||
stars: 1380 |
|||
owner_login: DjangoEx |
|||
owner_html_url: https://github.com/DjangoEx |
|||
- name: budgetml |
|||
html_url: https://github.com/ebhy/budgetml |
|||
stars: 1344 |
|||
owner_login: ebhy |
|||
owner_html_url: https://github.com/ebhy |
|||
- name: slowapi |
|||
html_url: https://github.com/laurentS/slowapi |
|||
stars: 1339 |
|||
owner_login: laurentS |
|||
owner_html_url: https://github.com/laurentS |
|||
- name: fastapi-pagination |
|||
html_url: https://github.com/uriyyo/fastapi-pagination |
|||
stars: 1263 |
|||
owner_login: uriyyo |
|||
owner_html_url: https://github.com/uriyyo |
|||
- name: fastapi-boilerplate |
|||
html_url: https://github.com/teamhide/fastapi-boilerplate |
|||
stars: 1206 |
|||
owner_login: teamhide |
|||
owner_html_url: https://github.com/teamhide |
|||
- name: fastapi-tutorial |
|||
html_url: https://github.com/liaogx/fastapi-tutorial |
|||
stars: 1178 |
|||
owner_login: liaogx |
|||
owner_html_url: https://github.com/liaogx |
|||
- name: fastapi-amis-admin |
|||
html_url: https://github.com/amisadmin/fastapi-amis-admin |
|||
stars: 1142 |
|||
owner_login: amisadmin |
|||
owner_html_url: https://github.com/amisadmin |
|||
- name: fastapi-code-generator |
|||
html_url: https://github.com/koxudaxi/fastapi-code-generator |
|||
stars: 1119 |
|||
owner_login: koxudaxi |
|||
owner_html_url: https://github.com/koxudaxi |
|||
- name: bolt-python |
|||
html_url: https://github.com/slackapi/bolt-python |
|||
stars: 1116 |
|||
owner_login: slackapi |
|||
owner_html_url: https://github.com/slackapi |
|||
- name: odmantic |
|||
html_url: https://github.com/art049/odmantic |
|||
stars: 1096 |
|||
owner_login: art049 |
|||
owner_html_url: https://github.com/art049 |
|||
- name: langchain-extract |
|||
html_url: https://github.com/langchain-ai/langchain-extract |
|||
stars: 1093 |
|||
owner_login: langchain-ai |
|||
owner_html_url: https://github.com/langchain-ai |
|||
- name: fastapi_production_template |
|||
html_url: https://github.com/zhanymkanov/fastapi_production_template |
|||
stars: 1078 |
|||
owner_login: zhanymkanov |
|||
owner_html_url: https://github.com/zhanymkanov |
|||
- name: fastapi-alembic-sqlmodel-async |
|||
html_url: https://github.com/jonra1993/fastapi-alembic-sqlmodel-async |
|||
stars: 1055 |
|||
owner_login: jonra1993 |
|||
owner_html_url: https://github.com/jonra1993 |
|||
- name: Kokoro-FastAPI |
|||
html_url: https://github.com/remsky/Kokoro-FastAPI |
|||
stars: 1047 |
|||
owner_login: remsky |
|||
owner_html_url: https://github.com/remsky |
|||
- name: prometheus-fastapi-instrumentator |
|||
html_url: https://github.com/trallnag/prometheus-fastapi-instrumentator |
|||
stars: 1036 |
|||
owner_login: trallnag |
|||
owner_html_url: https://github.com/trallnag |
|||
- name: SurfSense |
|||
html_url: https://github.com/MODSetter/SurfSense |
|||
stars: 1018 |
|||
owner_login: MODSetter |
|||
owner_html_url: https://github.com/MODSetter |
|||
- name: bedrock-claude-chat |
|||
html_url: https://github.com/aws-samples/bedrock-claude-chat |
|||
stars: 1010 |
|||
owner_login: aws-samples |
|||
owner_html_url: https://github.com/aws-samples |
|||
- name: runhouse |
|||
html_url: https://github.com/run-house/runhouse |
|||
stars: 1000 |
|||
owner_login: run-house |
|||
owner_html_url: https://github.com/run-house |
|||
- name: lanarky |
|||
html_url: https://github.com/ajndkr/lanarky |
|||
stars: 986 |
|||
owner_login: ajndkr |
|||
owner_html_url: https://github.com/ajndkr |
|||
- name: autollm |
|||
html_url: https://github.com/viddexa/autollm |
|||
stars: 982 |
|||
owner_login: viddexa |
|||
owner_html_url: https://github.com/viddexa |
|||
- name: restish |
|||
html_url: https://github.com/danielgtaylor/restish |
|||
stars: 970 |
|||
owner_login: danielgtaylor |
|||
owner_html_url: https://github.com/danielgtaylor |
|||
- name: fastcrud |
|||
html_url: https://github.com/igorbenav/fastcrud |
|||
stars: 929 |
|||
owner_login: igorbenav |
|||
owner_html_url: https://github.com/igorbenav |
|||
- name: secure |
|||
html_url: https://github.com/TypeError/secure |
|||
stars: 921 |
|||
owner_login: TypeError |
|||
owner_html_url: https://github.com/TypeError |
|||
- name: langcorn |
|||
html_url: https://github.com/msoedov/langcorn |
|||
stars: 915 |
|||
owner_login: msoedov |
|||
owner_html_url: https://github.com/msoedov |
|||
- name: vue-fastapi-admin |
|||
html_url: https://github.com/mizhexiaoxiao/vue-fastapi-admin |
|||
stars: 915 |
|||
owner_login: mizhexiaoxiao |
|||
owner_html_url: https://github.com/mizhexiaoxiao |
|||
- name: energy-forecasting |
|||
html_url: https://github.com/iusztinpaul/energy-forecasting |
|||
stars: 891 |
|||
owner_login: iusztinpaul |
|||
owner_html_url: https://github.com/iusztinpaul |
|||
- name: authx |
|||
html_url: https://github.com/yezz123/authx |
|||
stars: 862 |
|||
owner_login: yezz123 |
|||
owner_html_url: https://github.com/yezz123 |
|||
- name: titiler |
|||
html_url: https://github.com/developmentseed/titiler |
|||
stars: 823 |
|||
owner_login: developmentseed |
|||
owner_html_url: https://github.com/developmentseed |
|||
- name: marker-api |
|||
html_url: https://github.com/adithya-s-k/marker-api |
|||
stars: 798 |
|||
owner_login: adithya-s-k |
|||
owner_html_url: https://github.com/adithya-s-k |
|||
- name: FastAPI-boilerplate |
|||
html_url: https://github.com/igorbenav/FastAPI-boilerplate |
|||
stars: 774 |
|||
owner_login: igorbenav |
|||
owner_html_url: https://github.com/igorbenav |
|||
- name: fastapi_best_architecture |
|||
html_url: https://github.com/fastapi-practices/fastapi_best_architecture |
|||
stars: 766 |
|||
owner_login: fastapi-practices |
|||
owner_html_url: https://github.com/fastapi-practices |
|||
- name: fastapi-mail |
|||
html_url: https://github.com/sabuhish/fastapi-mail |
|||
stars: 735 |
|||
owner_login: sabuhish |
|||
owner_html_url: https://github.com/sabuhish |
|||
- name: annotated-py-projects |
|||
html_url: https://github.com/hhstore/annotated-py-projects |
|||
stars: 725 |
|||
owner_login: hhstore |
|||
owner_html_url: https://github.com/hhstore |
|||
- name: fastapi-do-zero |
|||
html_url: https://github.com/dunossauro/fastapi-do-zero |
|||
stars: 723 |
|||
owner_login: dunossauro |
|||
owner_html_url: https://github.com/dunossauro |
|||
- name: lccn_predictor |
|||
html_url: https://github.com/baoliay2008/lccn_predictor |
|||
stars: 718 |
|||
owner_login: baoliay2008 |
|||
owner_html_url: https://github.com/baoliay2008 |
|||
- name: fastapi-observability |
|||
html_url: https://github.com/blueswen/fastapi-observability |
|||
stars: 718 |
|||
owner_login: blueswen |
|||
owner_html_url: https://github.com/blueswen |
|||
- name: chatGPT-web |
|||
html_url: https://github.com/mic1on/chatGPT-web |
|||
stars: 708 |
|||
owner_login: mic1on |
|||
owner_html_url: https://github.com/mic1on |
|||
- name: learn-generative-ai |
|||
html_url: https://github.com/panaverse/learn-generative-ai |
|||
stars: 701 |
|||
owner_login: panaverse |
|||
owner_html_url: https://github.com/panaverse |
|||
- name: linbing |
|||
html_url: https://github.com/taomujian/linbing |
|||
stars: 700 |
|||
owner_login: taomujian |
|||
owner_html_url: https://github.com/taomujian |
|||
- name: FastAPI-Backend-Template |
|||
html_url: https://github.com/Aeternalis-Ingenium/FastAPI-Backend-Template |
|||
stars: 692 |
|||
owner_login: Aeternalis-Ingenium |
|||
owner_html_url: https://github.com/Aeternalis-Ingenium |
|||
- name: starlette-admin |
|||
html_url: https://github.com/jowilf/starlette-admin |
|||
stars: 692 |
|||
owner_login: jowilf |
|||
owner_html_url: https://github.com/jowilf |
|||
- name: fastapi-jwt-auth |
|||
html_url: https://github.com/IndominusByte/fastapi-jwt-auth |
|||
stars: 674 |
|||
owner_login: IndominusByte |
|||
owner_html_url: https://github.com/IndominusByte |
|||
- name: pity |
|||
html_url: https://github.com/wuranxu/pity |
|||
stars: 663 |
|||
owner_login: wuranxu |
|||
owner_html_url: https://github.com/wuranxu |
|||
- name: fastapi_login |
|||
html_url: https://github.com/MushroomMaula/fastapi_login |
|||
stars: 656 |
|||
owner_login: MushroomMaula |
|||
owner_html_url: https://github.com/MushroomMaula |
@ -0,0 +1,495 @@ |
|||
nilslindemann: |
|||
login: nilslindemann |
|||
count: 120 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/6892179?u=1dca6a22195d6cd1ab20737c0e19a4c55d639472&v=4 |
|||
url: https://github.com/nilslindemann |
|||
jaystone776: |
|||
login: jaystone776 |
|||
count: 46 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/11191137?u=299205a95e9b6817a43144a48b643346a5aac5cc&v=4 |
|||
url: https://github.com/jaystone776 |
|||
ceb10n: |
|||
login: ceb10n |
|||
count: 26 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/235213?u=edcce471814a1eba9f0cdaa4cd0de18921a940a6&v=4 |
|||
url: https://github.com/ceb10n |
|||
tokusumi: |
|||
login: tokusumi |
|||
count: 23 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/41147016?u=55010621aece725aa702270b54fed829b6a1fe60&v=4 |
|||
url: https://github.com/tokusumi |
|||
SwftAlpc: |
|||
login: SwftAlpc |
|||
count: 23 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/52768429?u=6a3aa15277406520ad37f6236e89466ed44bc5b8&v=4 |
|||
url: https://github.com/SwftAlpc |
|||
hasansezertasan: |
|||
login: hasansezertasan |
|||
count: 22 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/13135006?u=99f0b0f0fc47e88e8abb337b4447357939ef93e7&v=4 |
|||
url: https://github.com/hasansezertasan |
|||
waynerv: |
|||
login: waynerv |
|||
count: 20 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/39515546?u=ec35139777597cdbbbddda29bf8b9d4396b429a9&v=4 |
|||
url: https://github.com/waynerv |
|||
AlertRED: |
|||
login: AlertRED |
|||
count: 16 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/15695000?u=f5a4944c6df443030409c88da7d7fa0b7ead985c&v=4 |
|||
url: https://github.com/AlertRED |
|||
hard-coders: |
|||
login: hard-coders |
|||
count: 15 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/9651103?u=95db33927bbff1ed1c07efddeb97ac2ff33068ed&v=4 |
|||
url: https://github.com/hard-coders |
|||
codingjenny: |
|||
login: codingjenny |
|||
count: 14 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/103817302?u=3a042740dc0ff58615da0d8679230966fd7693e8&v=4 |
|||
url: https://github.com/codingjenny |
|||
Xewus: |
|||
login: Xewus |
|||
count: 13 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/85196001?u=f8e2dc7e5104f109cef944af79050ea8d1b8f914&v=4 |
|||
url: https://github.com/Xewus |
|||
Joao-Pedro-P-Holanda: |
|||
login: Joao-Pedro-P-Holanda |
|||
count: 13 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/110267046?u=331bd016326dac4cf3df4848f6db2dbbf8b5f978&v=4 |
|||
url: https://github.com/Joao-Pedro-P-Holanda |
|||
Smlep: |
|||
login: Smlep |
|||
count: 11 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/16785985?u=ffe99fa954c8e774ef1117e58d34aece92051e27&v=4 |
|||
url: https://github.com/Smlep |
|||
marcelomarkus: |
|||
login: marcelomarkus |
|||
count: 11 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/20115018?u=dda090ce9160ef0cd2ff69b1e5ea741283425cba&v=4 |
|||
url: https://github.com/marcelomarkus |
|||
KaniKim: |
|||
login: KaniKim |
|||
count: 10 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/19832624?u=296dbdd490e0eb96e3d45a2608c065603b17dc31&v=4 |
|||
url: https://github.com/KaniKim |
|||
Vincy1230: |
|||
login: Vincy1230 |
|||
count: 9 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/81342412?u=ab5e256a4077a4a91f3f9cd2115ba80780454cbe&v=4 |
|||
url: https://github.com/Vincy1230 |
|||
Zhongheng-Cheng: |
|||
login: Zhongheng-Cheng |
|||
count: 9 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/95612344?u=a0f7730a3cc7486827965e01a119ad610bda4b0a&v=4 |
|||
url: https://github.com/Zhongheng-Cheng |
|||
rjNemo: |
|||
login: rjNemo |
|||
count: 8 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/56785022?u=d5c3a02567c8649e146fcfc51b6060ccaf8adef8&v=4 |
|||
url: https://github.com/rjNemo |
|||
xzmeng: |
|||
login: xzmeng |
|||
count: 8 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/40202897?v=4 |
|||
url: https://github.com/xzmeng |
|||
pablocm83: |
|||
login: pablocm83 |
|||
count: 8 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/28315068?u=3310fbb05bb8bfc50d2c48b6cb64ac9ee4a14549&v=4 |
|||
url: https://github.com/pablocm83 |
|||
batlopes: |
|||
login: batlopes |
|||
count: 6 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/33462923?u=0fb3d7acb316764616f11e4947faf080e49ad8d9&v=4 |
|||
url: https://github.com/batlopes |
|||
lucasbalieiro: |
|||
login: lucasbalieiro |
|||
count: 6 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/37416577?u=5a395a69384e7fa0f9840ea32ef963d3f1cd9da4&v=4 |
|||
url: https://github.com/lucasbalieiro |
|||
Alexandrhub: |
|||
login: Alexandrhub |
|||
count: 6 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/119126536?u=9fc0d48f3307817bafecc5861eb2168401a6cb04&v=4 |
|||
url: https://github.com/Alexandrhub |
|||
Serrones: |
|||
login: Serrones |
|||
count: 5 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/22691749?u=4795b880e13ca33a73e52fc0ef7dc9c60c8fce47&v=4 |
|||
url: https://github.com/Serrones |
|||
RunningIkkyu: |
|||
login: RunningIkkyu |
|||
count: 5 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/31848542?u=494ecc298e3f26197495bb357ad0f57cfd5f7a32&v=4 |
|||
url: https://github.com/RunningIkkyu |
|||
Attsun1031: |
|||
login: Attsun1031 |
|||
count: 5 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/1175560?v=4 |
|||
url: https://github.com/Attsun1031 |
|||
NinaHwang: |
|||
login: NinaHwang |
|||
count: 5 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/79563565?u=241f2cb6d38a2d379536608a8ea5a22ed4b1a3ea&v=4 |
|||
url: https://github.com/NinaHwang |
|||
tiangolo: |
|||
login: tiangolo |
|||
count: 5 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/1326112?u=cb5d06e73a9e1998141b1641aa88e443c6717651&v=4 |
|||
url: https://github.com/tiangolo |
|||
rostik1410: |
|||
login: rostik1410 |
|||
count: 5 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/11443899?u=e26a635c2ba220467b308a326a579b8ccf4a8701&v=4 |
|||
url: https://github.com/rostik1410 |
|||
komtaki: |
|||
login: komtaki |
|||
count: 4 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/39375566?u=260ad6b1a4b34c07dbfa728da5e586f16f6d1824&v=4 |
|||
url: https://github.com/komtaki |
|||
JulianMaurin: |
|||
login: JulianMaurin |
|||
count: 4 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/63545168?u=b7d15ac865268cbefc2d739e2f23d9aeeac1a622&v=4 |
|||
url: https://github.com/JulianMaurin |
|||
stlucasgarcia: |
|||
login: stlucasgarcia |
|||
count: 4 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/61513630?u=c22d8850e9dc396a8820766a59837f967e14f9a0&v=4 |
|||
url: https://github.com/stlucasgarcia |
|||
ComicShrimp: |
|||
login: ComicShrimp |
|||
count: 4 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/43503750?u=d2fbf412e7730183ce91686ca48d4147e1b7dc74&v=4 |
|||
url: https://github.com/ComicShrimp |
|||
BilalAlpaslan: |
|||
login: BilalAlpaslan |
|||
count: 4 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/47563997?u=63ed66e304fe8d765762c70587d61d9196e5c82d&v=4 |
|||
url: https://github.com/BilalAlpaslan |
|||
axel584: |
|||
login: axel584 |
|||
count: 4 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/1334088?u=9667041f5b15dc002b6f9665fda8c0412933ac04&v=4 |
|||
url: https://github.com/axel584 |
|||
tamtam-fitness: |
|||
login: tamtam-fitness |
|||
count: 4 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/62091034?u=8da19a6bd3d02f5d6ba30c7247d5b46c98dd1403&v=4 |
|||
url: https://github.com/tamtam-fitness |
|||
Limsunoh: |
|||
login: Limsunoh |
|||
count: 4 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/90311848?u=f456e0c5709fd50c8cd2898b551558eda14e5f21&v=4 |
|||
url: https://github.com/Limsunoh |
|||
kwang1215: |
|||
login: kwang1215 |
|||
count: 4 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/74170199?u=2a63ff6692119dde3f5e5693365b9fcd6f977b08&v=4 |
|||
url: https://github.com/kwang1215 |
|||
alv2017: |
|||
login: alv2017 |
|||
count: 4 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/31544722?v=4 |
|||
url: https://github.com/alv2017 |
|||
jfunez: |
|||
login: jfunez |
|||
count: 3 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/805749?v=4 |
|||
url: https://github.com/jfunez |
|||
ycd: |
|||
login: ycd |
|||
count: 3 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/62724709?u=29682e4b6ac7d5293742ccf818188394b9a82972&v=4 |
|||
url: https://github.com/ycd |
|||
mariacamilagl: |
|||
login: mariacamilagl |
|||
count: 3 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/11489395?u=4adb6986bf3debfc2b8216ae701f2bd47d73da7d&v=4 |
|||
url: https://github.com/mariacamilagl |
|||
maoyibo: |
|||
login: maoyibo |
|||
count: 3 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/7887703?v=4 |
|||
url: https://github.com/maoyibo |
|||
blt232018: |
|||
login: blt232018 |
|||
count: 3 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/43393471?u=172b0e0391db1aa6c1706498d6dfcb003c8a4857&v=4 |
|||
url: https://github.com/blt232018 |
|||
magiskboy: |
|||
login: magiskboy |
|||
count: 3 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/13352088?u=18b6d672523f9e9d98401f31dd50e28bb27d826f&v=4 |
|||
url: https://github.com/magiskboy |
|||
luccasmmg: |
|||
login: luccasmmg |
|||
count: 3 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/11317382?u=65099a5a0d492b89119471f8a7014637cc2e04da&v=4 |
|||
url: https://github.com/luccasmmg |
|||
lbmendes: |
|||
login: lbmendes |
|||
count: 3 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/80999926?u=646619e2f07ac5a7c3f65fe7834197461a4fff9f&v=4 |
|||
url: https://github.com/lbmendes |
|||
Zssaer: |
|||
login: Zssaer |
|||
count: 3 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/45691504?u=4c0c195f25cb5ac6af32acfb0ab35427682938d2&v=4 |
|||
url: https://github.com/Zssaer |
|||
wdh99: |
|||
login: wdh99 |
|||
count: 3 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/108172295?u=8a8fb95d5afe3e0fa33257b2aecae88d436249eb&v=4 |
|||
url: https://github.com/wdh99 |
|||
ChuyuChoyeon: |
|||
login: ChuyuChoyeon |
|||
count: 3 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/129537877?u=f0c76f3327817a8b86b422d62e04a34bf2827f2b&v=4 |
|||
url: https://github.com/ChuyuChoyeon |
|||
ivan-abc: |
|||
login: ivan-abc |
|||
count: 3 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/36765187?u=c6e0ba571c1ccb6db9d94e62e4b8b5eda811a870&v=4 |
|||
url: https://github.com/ivan-abc |
|||
mojtabapaso: |
|||
login: mojtabapaso |
|||
count: 3 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/121169359?u=ced1d5ad673bcd9e949ebf967a4ab50185637443&v=4 |
|||
url: https://github.com/mojtabapaso |
|||
hsuanchi: |
|||
login: hsuanchi |
|||
count: 3 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/24913710?u=0b094ae292292fee093818e37ceb645c114d2bff&v=4 |
|||
url: https://github.com/hsuanchi |
|||
alejsdev: |
|||
login: alejsdev |
|||
count: 3 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/90076947?u=356f39ff3f0211c720b06d3dbb060e98884085e3&v=4 |
|||
url: https://github.com/alejsdev |
|||
riroan: |
|||
login: riroan |
|||
count: 3 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/33053284?u=2d18e3771506ee874b66d6aa2b3b1107fd95c38f&v=4 |
|||
url: https://github.com/riroan |
|||
nayeonkinn: |
|||
login: nayeonkinn |
|||
count: 3 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/98254573?u=64a75ac99b320d4935eff8d1fceea9680fa07473&v=4 |
|||
url: https://github.com/nayeonkinn |
|||
pe-brian: |
|||
login: pe-brian |
|||
count: 3 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/1783138?u=7e6242eb9e85bcf673fa88bbac9dd6dc3f03b1b5&v=4 |
|||
url: https://github.com/pe-brian |
|||
maxscheijen: |
|||
login: maxscheijen |
|||
count: 3 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/47034840?u=eb98f37882528ea349ca4e5255fa64ac3fef0294&v=4 |
|||
url: https://github.com/maxscheijen |
|||
ilacftemp: |
|||
login: ilacftemp |
|||
count: 3 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/159066669?v=4 |
|||
url: https://github.com/ilacftemp |
|||
devluisrodrigues: |
|||
login: devluisrodrigues |
|||
count: 3 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/103431660?u=d9674a3249edc4601d2c712cdebf899918503c3a&v=4 |
|||
url: https://github.com/devluisrodrigues |
|||
devfernandoa: |
|||
login: devfernandoa |
|||
count: 3 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/28360583?u=c4308abd62e8847c9e572e1bb9fe6b9dc9ef8e50&v=4 |
|||
url: https://github.com/devfernandoa |
|||
kim-sangah: |
|||
login: kim-sangah |
|||
count: 3 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/173775778?v=4 |
|||
url: https://github.com/kim-sangah |
|||
9zimin9: |
|||
login: 9zimin9 |
|||
count: 3 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/174453744?v=4 |
|||
url: https://github.com/9zimin9 |
|||
nahyunkeem: |
|||
login: nahyunkeem |
|||
count: 3 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/174440096?u=e12401d492eee58570f8914d0872b52e421a776e&v=4 |
|||
url: https://github.com/nahyunkeem |
|||
gerry-sabar: |
|||
login: gerry-sabar |
|||
count: 3 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/1120123?v=4 |
|||
url: https://github.com/gerry-sabar |
|||
izaguerreiro: |
|||
login: izaguerreiro |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/2241504?v=4 |
|||
url: https://github.com/izaguerreiro |
|||
Xaraxx: |
|||
login: Xaraxx |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/29824698?u=dde2e233e22bb5ca1f8bb0c6e353ccd0d06e6066&v=4 |
|||
url: https://github.com/Xaraxx |
|||
sh0nk: |
|||
login: sh0nk |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/6478810?u=af15d724875cec682ed8088a86d36b2798f981c0&v=4 |
|||
url: https://github.com/sh0nk |
|||
dukkee: |
|||
login: dukkee |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/36825394?u=ccfd86e6a4f2d093dad6f7544cc875af67fa2df8&v=4 |
|||
url: https://github.com/dukkee |
|||
oandersonmagalhaes: |
|||
login: oandersonmagalhaes |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/83456692?v=4 |
|||
url: https://github.com/oandersonmagalhaes |
|||
leandrodesouzadev: |
|||
login: leandrodesouzadev |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/85115541?u=4eb25f43f1fe23727d61e986cf83b73b86e2a95a&v=4 |
|||
url: https://github.com/leandrodesouzadev |
|||
kty4119: |
|||
login: kty4119 |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/49435654?v=4 |
|||
url: https://github.com/kty4119 |
|||
ASpathfinder: |
|||
login: ASpathfinder |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/31813636?u=2090bd1b7abb65cfeff0c618f99f11afa82c0548&v=4 |
|||
url: https://github.com/ASpathfinder |
|||
jujumilk3: |
|||
login: jujumilk3 |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/41659814?u=538f7dfef03b59f25e43f10d59a31c19ef538a0c&v=4 |
|||
url: https://github.com/jujumilk3 |
|||
ayr-ton: |
|||
login: ayr-ton |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/1090517?u=5cf70a0e0f0dbf084e074e494aa94d7c91a46ba6&v=4 |
|||
url: https://github.com/ayr-ton |
|||
KdHyeon0661: |
|||
login: KdHyeon0661 |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/20253352?u=5ae1aae34b091a39f22cbe60a02b79dcbdbea031&v=4 |
|||
url: https://github.com/KdHyeon0661 |
|||
LorhanSohaky: |
|||
login: LorhanSohaky |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/16273730?u=095b66f243a2cd6a0aadba9a095009f8aaf18393&v=4 |
|||
url: https://github.com/LorhanSohaky |
|||
cfraboulet: |
|||
login: cfraboulet |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/62244267?u=ed0e286ba48fa1dafd64a08e50f3364b8e12df34&v=4 |
|||
url: https://github.com/cfraboulet |
|||
dedkot01: |
|||
login: dedkot01 |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/26196675?u=e2966887124e67932853df4f10f86cb526edc7b0&v=4 |
|||
url: https://github.com/dedkot01 |
|||
AGolicyn: |
|||
login: AGolicyn |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/86262613?u=3c21606ab8d210a061a1673decff1e7d5592b380&v=4 |
|||
url: https://github.com/AGolicyn |
|||
fhabers21: |
|||
login: fhabers21 |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/58401847?v=4 |
|||
url: https://github.com/fhabers21 |
|||
TabarakoAkula: |
|||
login: TabarakoAkula |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/113298631?u=add801e370dbc502cd94ce6d3484760d7fef5406&v=4 |
|||
url: https://github.com/TabarakoAkula |
|||
AhsanSheraz: |
|||
login: AhsanSheraz |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/51913596?u=08e31cacb3048be30722c94010ddd028f3fdbec4&v=4 |
|||
url: https://github.com/AhsanSheraz |
|||
ArtemKhymenko: |
|||
login: ArtemKhymenko |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/14346625?u=f2fa553d9e5ec5e0f05d66bd649f7be347169631&v=4 |
|||
url: https://github.com/ArtemKhymenko |
|||
hasnatsajid: |
|||
login: hasnatsajid |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/86589885?u=49958789e6385be624f2c6a55a860c599eb05e2c&v=4 |
|||
url: https://github.com/hasnatsajid |
|||
alperiox: |
|||
login: alperiox |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/34214152?u=2c5acad3461d4dbc2d48371ba86cac56ae9b25cc&v=4 |
|||
url: https://github.com/alperiox |
|||
emrhnsyts: |
|||
login: emrhnsyts |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/42899027?u=ad26798e3f8feed2041c5dd5f87e58933d6c3283&v=4 |
|||
url: https://github.com/emrhnsyts |
|||
vusallyv: |
|||
login: vusallyv |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/85983771?u=53a7b755cb338d9313966dbf2e4e68b512565186&v=4 |
|||
url: https://github.com/vusallyv |
|||
jackleeio: |
|||
login: jackleeio |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/20477587?u=c5184dab6d021733d10c8f975b20e391856303d6&v=4 |
|||
url: https://github.com/jackleeio |
|||
choi-haram: |
|||
login: choi-haram |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/62204475?v=4 |
|||
url: https://github.com/choi-haram |
|||
imtiaz101325: |
|||
login: imtiaz101325 |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/54007087?u=7a210ee38a0a30b7536226419b3b799620ad57d9&v=4 |
|||
url: https://github.com/imtiaz101325 |
|||
waketzheng: |
|||
login: waketzheng |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/35413830?u=df19e4fd5bb928e7d086e053ef26a46aad23bf84&v=4 |
|||
url: https://github.com/waketzheng |
|||
billzhong: |
|||
login: billzhong |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/1644011?v=4 |
|||
url: https://github.com/billzhong |
|||
chaoless: |
|||
login: chaoless |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/64477804?v=4 |
|||
url: https://github.com/chaoless |
|||
logan2d5: |
|||
login: logan2d5 |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/146642263?u=dbd6621f8b0330d6919f6a7131277b92e26fbe87&v=4 |
|||
url: https://github.com/logan2d5 |
|||
andersonrocha0: |
|||
login: andersonrocha0 |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/22346169?u=93a1359c8c5461d894802c0cc65bcd09217e7a02&v=4 |
|||
url: https://github.com/andersonrocha0 |
|||
saeye: |
|||
login: saeye |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/62229734?v=4 |
|||
url: https://github.com/saeye |
|||
timothy-jeong: |
|||
login: timothy-jeong |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/53824764?u=db3d0cea2f5fab64d810113c5039a369699a2774&v=4 |
|||
url: https://github.com/timothy-jeong |
|||
Rishat-F: |
|||
login: Rishat-F |
|||
count: 2 |
|||
avatarUrl: https://avatars.githubusercontent.com/u/66554797?v=4 |
|||
url: https://github.com/Rishat-F |
After Width: | Height: | Size: 9.3 KiB |
After Width: | Height: | Size: 21 KiB |
After Width: | Height: | Size: 6.2 KiB |
After Width: | Height: | Size: 38 KiB |
Before Width: | Height: | Size: 4.7 KiB After Width: | Height: | Size: 12 KiB |
Before Width: | Height: | Size: 40 KiB After Width: | Height: | Size: 44 KiB |
@ -0,0 +1,247 @@ |
|||
# Responses Adicionales en OpenAPI |
|||
|
|||
/// warning | Advertencia |
|||
|
|||
Este es un tema bastante avanzado. |
|||
|
|||
Si estás comenzando con **FastAPI**, puede que no lo necesites. |
|||
|
|||
/// |
|||
|
|||
Puedes declarar responses adicionales, con códigos de estado adicionales, media types, descripciones, etc. |
|||
|
|||
Esos responses adicionales se incluirán en el esquema de OpenAPI, por lo que también aparecerán en la documentación de la API. |
|||
|
|||
Pero para esos responses adicionales tienes que asegurarte de devolver un `Response` como `JSONResponse` directamente, con tu código de estado y contenido. |
|||
|
|||
## Response Adicional con `model` |
|||
|
|||
Puedes pasar a tus *decoradores de path operation* un parámetro `responses`. |
|||
|
|||
Recibe un `dict`: las claves son los códigos de estado para cada response (como `200`), y los valores son otros `dict`s con la información para cada uno de ellos. |
|||
|
|||
Cada uno de esos `dict`s de response puede tener una clave `model`, conteniendo un modelo de Pydantic, así como `response_model`. |
|||
|
|||
**FastAPI** tomará ese modelo, generará su JSON Schema y lo incluirá en el lugar correcto en OpenAPI. |
|||
|
|||
Por ejemplo, para declarar otro response con un código de estado `404` y un modelo Pydantic `Message`, puedes escribir: |
|||
|
|||
{* ../../docs_src/additional_responses/tutorial001.py hl[18,22] *} |
|||
|
|||
/// note | Nota |
|||
|
|||
Ten en cuenta que debes devolver el `JSONResponse` directamente. |
|||
|
|||
/// |
|||
|
|||
/// info | Información |
|||
|
|||
La clave `model` no es parte de OpenAPI. |
|||
|
|||
**FastAPI** tomará el modelo de Pydantic de allí, generará el JSON Schema y lo colocará en el lugar correcto. |
|||
|
|||
El lugar correcto es: |
|||
|
|||
* En la clave `content`, que tiene como valor otro objeto JSON (`dict`) que contiene: |
|||
* Una clave con el media type, por ejemplo, `application/json`, que contiene como valor otro objeto JSON, que contiene: |
|||
* Una clave `schema`, que tiene como valor el JSON Schema del modelo, aquí es el lugar correcto. |
|||
* **FastAPI** agrega una referencia aquí a los JSON Schemas globales en otro lugar de tu OpenAPI en lugar de incluirlo directamente. De este modo, otras aplicaciones y clientes pueden usar esos JSON Schemas directamente, proporcionar mejores herramientas de generación de código, etc. |
|||
|
|||
/// |
|||
|
|||
Los responses generadas en el OpenAPI para esta *path operation* serán: |
|||
|
|||
```JSON hl_lines="3-12" |
|||
{ |
|||
"responses": { |
|||
"404": { |
|||
"description": "Additional Response", |
|||
"content": { |
|||
"application/json": { |
|||
"schema": { |
|||
"$ref": "#/components/schemas/Message" |
|||
} |
|||
} |
|||
} |
|||
}, |
|||
"200": { |
|||
"description": "Successful Response", |
|||
"content": { |
|||
"application/json": { |
|||
"schema": { |
|||
"$ref": "#/components/schemas/Item" |
|||
} |
|||
} |
|||
} |
|||
}, |
|||
"422": { |
|||
"description": "Validation Error", |
|||
"content": { |
|||
"application/json": { |
|||
"schema": { |
|||
"$ref": "#/components/schemas/HTTPValidationError" |
|||
} |
|||
} |
|||
} |
|||
} |
|||
} |
|||
} |
|||
``` |
|||
|
|||
Los esquemas se referencian a otro lugar dentro del esquema de OpenAPI: |
|||
|
|||
```JSON hl_lines="4-16" |
|||
{ |
|||
"components": { |
|||
"schemas": { |
|||
"Message": { |
|||
"title": "Message", |
|||
"required": [ |
|||
"message" |
|||
], |
|||
"type": "object", |
|||
"properties": { |
|||
"message": { |
|||
"title": "Message", |
|||
"type": "string" |
|||
} |
|||
} |
|||
}, |
|||
"Item": { |
|||
"title": "Item", |
|||
"required": [ |
|||
"id", |
|||
"value" |
|||
], |
|||
"type": "object", |
|||
"properties": { |
|||
"id": { |
|||
"title": "Id", |
|||
"type": "string" |
|||
}, |
|||
"value": { |
|||
"title": "Value", |
|||
"type": "string" |
|||
} |
|||
} |
|||
}, |
|||
"ValidationError": { |
|||
"title": "ValidationError", |
|||
"required": [ |
|||
"loc", |
|||
"msg", |
|||
"type" |
|||
], |
|||
"type": "object", |
|||
"properties": { |
|||
"loc": { |
|||
"title": "Location", |
|||
"type": "array", |
|||
"items": { |
|||
"type": "string" |
|||
} |
|||
}, |
|||
"msg": { |
|||
"title": "Message", |
|||
"type": "string" |
|||
}, |
|||
"type": { |
|||
"title": "Error Type", |
|||
"type": "string" |
|||
} |
|||
} |
|||
}, |
|||
"HTTPValidationError": { |
|||
"title": "HTTPValidationError", |
|||
"type": "object", |
|||
"properties": { |
|||
"detail": { |
|||
"title": "Detail", |
|||
"type": "array", |
|||
"items": { |
|||
"$ref": "#/components/schemas/ValidationError" |
|||
} |
|||
} |
|||
} |
|||
} |
|||
} |
|||
} |
|||
} |
|||
``` |
|||
|
|||
## Media types adicionales para el response principal |
|||
|
|||
Puedes usar este mismo parámetro `responses` para agregar diferentes media type para el mismo response principal. |
|||
|
|||
Por ejemplo, puedes agregar un media type adicional de `image/png`, declarando que tu *path operation* puede devolver un objeto JSON (con media type `application/json`) o una imagen PNG: |
|||
|
|||
{* ../../docs_src/additional_responses/tutorial002.py hl[19:24,28] *} |
|||
|
|||
/// note | Nota |
|||
|
|||
Nota que debes devolver la imagen usando un `FileResponse` directamente. |
|||
|
|||
/// |
|||
|
|||
/// info | Información |
|||
|
|||
A menos que especifiques un media type diferente explícitamente en tu parámetro `responses`, FastAPI asumirá que el response tiene el mismo media type que la clase de response principal (por defecto `application/json`). |
|||
|
|||
Pero si has especificado una clase de response personalizada con `None` como su media type, FastAPI usará `application/json` para cualquier response adicional que tenga un modelo asociado. |
|||
|
|||
/// |
|||
|
|||
## Combinando información |
|||
|
|||
También puedes combinar información de response de múltiples lugares, incluyendo los parámetros `response_model`, `status_code`, y `responses`. |
|||
|
|||
Puedes declarar un `response_model`, usando el código de estado predeterminado `200` (o uno personalizado si lo necesitas), y luego declarar información adicional para ese mismo response en `responses`, directamente en el esquema de OpenAPI. |
|||
|
|||
**FastAPI** manterá la información adicional de `responses` y la combinará con el JSON Schema de tu modelo. |
|||
|
|||
Por ejemplo, puedes declarar un response con un código de estado `404` que usa un modelo Pydantic y tiene una `description` personalizada. |
|||
|
|||
Y un response con un código de estado `200` que usa tu `response_model`, pero incluye un `example` personalizado: |
|||
|
|||
{* ../../docs_src/additional_responses/tutorial003.py hl[20:31] *} |
|||
|
|||
Todo se combinará e incluirá en tu OpenAPI, y se mostrará en la documentación de la API: |
|||
|
|||
<img src="/img/tutorial/additional-responses/image01.png"> |
|||
|
|||
## Combina responses predefinidos y personalizados |
|||
|
|||
Es posible que desees tener algunos responses predefinidos que se apliquen a muchas *path operations*, pero que quieras combinarlos con responses personalizados necesarios por cada *path operation*. |
|||
|
|||
Para esos casos, puedes usar la técnica de Python de "desempaquetar" un `dict` con `**dict_to_unpack`: |
|||
|
|||
```Python |
|||
old_dict = { |
|||
"old key": "old value", |
|||
"second old key": "second old value", |
|||
} |
|||
new_dict = {**old_dict, "new key": "new value"} |
|||
``` |
|||
|
|||
Aquí, `new_dict` contendrá todos los pares clave-valor de `old_dict` más el nuevo par clave-valor: |
|||
|
|||
```Python |
|||
{ |
|||
"old key": "old value", |
|||
"second old key": "second old value", |
|||
"new key": "new value", |
|||
} |
|||
``` |
|||
|
|||
Puedes usar esa técnica para reutilizar algunos responses predefinidos en tus *path operations* y combinarlos con otros personalizados adicionales. |
|||
|
|||
Por ejemplo: |
|||
|
|||
{* ../../docs_src/additional_responses/tutorial004.py hl[13:17,26] *} |
|||
|
|||
## Más información sobre responses OpenAPI |
|||
|
|||
Para ver exactamente qué puedes incluir en los responses, puedes revisar estas secciones en la especificación OpenAPI: |
|||
|
|||
* <a href="https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.1.0.md#responses-object" class="external-link" target="_blank">Objeto de Responses de OpenAPI</a>, incluye el `Response Object`. |
|||
* <a href="https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.1.0.md#response-object" class="external-link" target="_blank">Objeto de Response de OpenAPI</a>, puedes incluir cualquier cosa de esto directamente en cada response dentro de tu parámetro `responses`. Incluyendo `description`, `headers`, `content` (dentro de este es que declaras diferentes media types y JSON Schemas), y `links`. |
@ -1,41 +1,41 @@ |
|||
# Códigos de estado adicionales |
|||
# Códigos de Estado Adicionales |
|||
|
|||
Por defecto, **FastAPI** devolverá las respuestas utilizando una `JSONResponse`, poniendo el contenido que devuelves en tu *operación de path* dentro de esa `JSONResponse`. |
|||
Por defecto, **FastAPI** devolverá los responses usando un `JSONResponse`, colocando el contenido que devuelves desde tu *path operation* dentro de ese `JSONResponse`. |
|||
|
|||
Utilizará el código de estado por defecto, o el que hayas asignado en tu *operación de path*. |
|||
Usará el código de estado por defecto o el que configures en tu *path operation*. |
|||
|
|||
## Códigos de estado adicionales |
|||
|
|||
Si quieres devolver códigos de estado adicionales además del principal, puedes hacerlo devolviendo directamente una `Response`, como una `JSONResponse`, y asignar directamente el código de estado adicional. |
|||
Si quieres devolver códigos de estado adicionales aparte del principal, puedes hacerlo devolviendo un `Response` directamente, como un `JSONResponse`, y configurando el código de estado adicional directamente. |
|||
|
|||
Por ejemplo, digamos que quieres tener una *operación de path* que permita actualizar ítems y devolver códigos de estado HTTP 200 "OK" cuando sea exitosa. |
|||
Por ejemplo, supongamos que quieres tener una *path operation* que permita actualizar elementos, y devuelva códigos de estado HTTP de 200 "OK" cuando sea exitoso. |
|||
|
|||
Pero también quieres que acepte nuevos ítems. Cuando los ítems no existan anteriormente, serán creados y devolverá un código de estado HTTP 201 "Created". |
|||
Pero también quieres que acepte nuevos elementos. Y cuando los elementos no existían antes, los crea y devuelve un código de estado HTTP de 201 "Created". |
|||
|
|||
Para conseguir esto importa `JSONResponse` y devuelve ahí directamente tu contenido, asignando el `status_code` que quieras: |
|||
Para lograr eso, importa `JSONResponse`, y devuelve tu contenido allí directamente, configurando el `status_code` que deseas: |
|||
|
|||
{* ../../docs_src/additional_status_codes/tutorial001.py hl[4,25] *} |
|||
{* ../../docs_src/additional_status_codes/tutorial001_an_py310.py hl[4,25] *} |
|||
|
|||
/// warning | Advertencia |
|||
|
|||
Cuando devuelves directamente una `Response`, como en los ejemplos anteriores, será devuelta directamente. |
|||
Cuando devuelves un `Response` directamente, como en el ejemplo anterior, se devuelve directamente. |
|||
|
|||
No será serializado con el modelo, etc. |
|||
No se serializará con un modelo, etc. |
|||
|
|||
Asegúrate de que la respuesta tenga los datos que quieras, y que los valores sean JSON válidos (si estás usando `JSONResponse`). |
|||
Asegúrate de que tenga los datos que deseas que tenga y que los valores sean JSON válidos (si estás usando `JSONResponse`). |
|||
|
|||
/// |
|||
|
|||
/// note | Detalles Técnicos |
|||
|
|||
También podrías utilizar `from starlette.responses import JSONResponse`. |
|||
También podrías usar `from starlette.responses import JSONResponse`. |
|||
|
|||
**FastAPI** provee las mismas `starlette.responses` que `fastapi.responses` simplemente como una convención para ti, el desarrollador. Pero la mayoría de las respuestas disponibles vienen directamente de Starlette. Lo mismo con `status`. |
|||
**FastAPI** proporciona los mismos `starlette.responses` que `fastapi.responses` solo como una conveniencia para ti, el desarrollador. Pero la mayoría de los responses disponibles provienen directamente de Starlette. Lo mismo con `status`. |
|||
|
|||
/// |
|||
|
|||
## OpenAPI y documentación de API |
|||
|
|||
Si quieres devolver códigos de estado y respuestas adicionales directamente, estas no estarán incluidas en el schema de OpenAPI (documentación de API), porque FastAPI no tiene una manera de conocer de antemano lo que vas a devolver. |
|||
Si devuelves códigos de estado adicionales y responses directamente, no se incluirán en el esquema de OpenAPI (la documentación de la API), porque FastAPI no tiene una forma de saber de antemano qué vas a devolver. |
|||
|
|||
Pero puedes documentar eso en tu código usando [Respuestas Adicionales](additional-responses.md){.internal-link target=_blank}. |
|||
Pero puedes documentarlo en tu código, usando: [Responses Adicionales](additional-responses.md){.internal-link target=_blank}. |
|||
|
@ -0,0 +1,65 @@ |
|||
# Dependencias Avanzadas |
|||
|
|||
## Dependencias con parámetros |
|||
|
|||
Todas las dependencias que hemos visto son una función o clase fija. |
|||
|
|||
Pero podría haber casos en los que quieras poder establecer parámetros en la dependencia, sin tener que declarar muchas funciones o clases diferentes. |
|||
|
|||
Imaginemos que queremos tener una dependencia que revise si el parámetro de query `q` contiene algún contenido fijo. |
|||
|
|||
Pero queremos poder parametrizar ese contenido fijo. |
|||
|
|||
## Una *instance* "callable" |
|||
|
|||
En Python hay una forma de hacer que una instance de una clase sea un "callable". |
|||
|
|||
No la clase en sí (que ya es un callable), sino una instance de esa clase. |
|||
|
|||
Para hacer eso, declaramos un método `__call__`: |
|||
|
|||
{* ../../docs_src/dependencies/tutorial011_an_py39.py hl[12] *} |
|||
|
|||
En este caso, este `__call__` es lo que **FastAPI** usará para comprobar parámetros adicionales y sub-dependencias, y es lo que llamará para pasar un valor al parámetro en tu *path operation function* más adelante. |
|||
|
|||
## Parametrizar la instance |
|||
|
|||
Y ahora, podemos usar `__init__` para declarar los parámetros de la instance que podemos usar para "parametrizar" la dependencia: |
|||
|
|||
{* ../../docs_src/dependencies/tutorial011_an_py39.py hl[9] *} |
|||
|
|||
En este caso, **FastAPI** nunca tocará ni se preocupará por `__init__`, lo usaremos directamente en nuestro código. |
|||
|
|||
## Crear una instance |
|||
|
|||
Podríamos crear una instance de esta clase con: |
|||
|
|||
{* ../../docs_src/dependencies/tutorial011_an_py39.py hl[18] *} |
|||
|
|||
Y de esa manera podemos "parametrizar" nuestra dependencia, que ahora tiene `"bar"` dentro de ella, como el atributo `checker.fixed_content`. |
|||
|
|||
## Usar la instance como una dependencia |
|||
|
|||
Luego, podríamos usar este `checker` en un `Depends(checker)`, en lugar de `Depends(FixedContentQueryChecker)`, porque la dependencia es la instance, `checker`, no la clase en sí. |
|||
|
|||
Y al resolver la dependencia, **FastAPI** llamará a este `checker` así: |
|||
|
|||
```Python |
|||
checker(q="somequery") |
|||
``` |
|||
|
|||
...y pasará lo que eso retorne como el valor de la dependencia en nuestra *path operation function* como el parámetro `fixed_content_included`: |
|||
|
|||
{* ../../docs_src/dependencies/tutorial011_an_py39.py hl[22] *} |
|||
|
|||
/// tip | Consejo |
|||
|
|||
Todo esto podría parecer complicado. Y puede que no esté muy claro cómo es útil aún. |
|||
|
|||
Estos ejemplos son intencionalmente simples, pero muestran cómo funciona todo. |
|||
|
|||
En los capítulos sobre seguridad, hay funciones utilitarias que se implementan de esta misma manera. |
|||
|
|||
Si entendiste todo esto, ya sabes cómo funcionan por debajo esas herramientas de utilidad para seguridad. |
|||
|
|||
/// |
@ -0,0 +1,99 @@ |
|||
# Tests Asíncronos |
|||
|
|||
Ya has visto cómo probar tus aplicaciones de **FastAPI** usando el `TestClient` proporcionado. Hasta ahora, solo has visto cómo escribir tests sincrónicos, sin usar funciones `async`. |
|||
|
|||
Poder usar funciones asíncronas en tus tests puede ser útil, por ejemplo, cuando consultas tu base de datos de forma asíncrona. Imagina que quieres probar el envío de requests a tu aplicación FastAPI y luego verificar que tu backend escribió exitosamente los datos correctos en la base de datos, mientras usas un paquete de base de datos asíncrono. |
|||
|
|||
Veamos cómo podemos hacer que esto funcione. |
|||
|
|||
## pytest.mark.anyio |
|||
|
|||
Si queremos llamar funciones asíncronas en nuestros tests, nuestras funciones de test tienen que ser asíncronas. AnyIO proporciona un plugin útil para esto, que nos permite especificar que algunas funciones de test deben ser llamadas de manera asíncrona. |
|||
|
|||
## HTTPX |
|||
|
|||
Incluso si tu aplicación de **FastAPI** usa funciones `def` normales en lugar de `async def`, sigue siendo una aplicación `async` por debajo. |
|||
|
|||
El `TestClient` hace algo de magia interna para llamar a la aplicación FastAPI asíncrona en tus funciones de test `def` normales, usando pytest estándar. Pero esa magia ya no funciona cuando lo usamos dentro de funciones asíncronas. Al ejecutar nuestros tests de manera asíncrona, ya no podemos usar el `TestClient` dentro de nuestras funciones de test. |
|||
|
|||
El `TestClient` está basado en <a href="https://www.python-httpx.org" class="external-link" target="_blank">HTTPX</a>, y afortunadamente, podemos usarlo directamente para probar la API. |
|||
|
|||
## Ejemplo |
|||
|
|||
Para un ejemplo simple, consideremos una estructura de archivos similar a la descrita en [Aplicaciones Más Grandes](../tutorial/bigger-applications.md){.internal-link target=_blank} y [Testing](../tutorial/testing.md){.internal-link target=_blank}: |
|||
|
|||
``` |
|||
. |
|||
├── app |
|||
│ ├── __init__.py |
|||
│ ├── main.py |
|||
│ └── test_main.py |
|||
``` |
|||
|
|||
El archivo `main.py` tendría: |
|||
|
|||
{* ../../docs_src/async_tests/main.py *} |
|||
|
|||
El archivo `test_main.py` tendría los tests para `main.py`, podría verse así ahora: |
|||
|
|||
{* ../../docs_src/async_tests/test_main.py *} |
|||
|
|||
## Ejecútalo |
|||
|
|||
Puedes ejecutar tus tests como de costumbre vía: |
|||
|
|||
<div class="termy"> |
|||
|
|||
```console |
|||
$ pytest |
|||
|
|||
---> 100% |
|||
``` |
|||
|
|||
</div> |
|||
|
|||
## En Detalle |
|||
|
|||
El marcador `@pytest.mark.anyio` le dice a pytest que esta función de test debe ser llamada asíncronamente: |
|||
|
|||
{* ../../docs_src/async_tests/test_main.py hl[7] *} |
|||
|
|||
/// tip | Consejo |
|||
|
|||
Note que la función de test ahora es `async def` en lugar de solo `def` como antes al usar el `TestClient`. |
|||
|
|||
/// |
|||
|
|||
Luego podemos crear un `AsyncClient` con la app y enviar requests asíncronos a ella, usando `await`. |
|||
|
|||
{* ../../docs_src/async_tests/test_main.py hl[9:12] *} |
|||
|
|||
Esto es equivalente a: |
|||
|
|||
```Python |
|||
response = client.get('/') |
|||
``` |
|||
|
|||
...que usábamos para hacer nuestros requests con el `TestClient`. |
|||
|
|||
/// tip | Consejo |
|||
|
|||
Nota que estamos usando async/await con el nuevo `AsyncClient`: el request es asíncrono. |
|||
|
|||
/// |
|||
|
|||
/// warning | Advertencia |
|||
|
|||
Si tu aplicación depende de eventos de lifespan, el `AsyncClient` no activará estos eventos. Para asegurarte de que se activen, usa `LifespanManager` de <a href="https://github.com/florimondmanca/asgi-lifespan#usage" class="external-link" target="_blank">florimondmanca/asgi-lifespan</a>. |
|||
|
|||
/// |
|||
|
|||
## Otras Llamadas a Funciones Asíncronas |
|||
|
|||
Al ser la función de test asíncrona, ahora también puedes llamar (y `await`) otras funciones `async` además de enviar requests a tu aplicación FastAPI en tus tests, exactamente como las llamarías en cualquier otro lugar de tu código. |
|||
|
|||
/// tip | Consejo |
|||
|
|||
Si encuentras un `RuntimeError: Task attached to a different loop` al integrar llamadas a funciones asíncronas en tus tests (por ejemplo, cuando usas <a href="https://stackoverflow.com/questions/41584243/runtimeerror-task-attached-to-a-different-loop" class="external-link" target="_blank">MotorClient de MongoDB</a>), recuerda crear instances de objetos que necesiten un loop de eventos solo dentro de funciones async, por ejemplo, en un callback `'@app.on_event("startup")`. |
|||
|
|||
/// |
@ -0,0 +1,361 @@ |
|||
# Detrás de un Proxy |
|||
|
|||
En algunas situaciones, podrías necesitar usar un **proxy** como Traefik o Nginx con una configuración que añade un prefijo de path extra que no es visto por tu aplicación. |
|||
|
|||
En estos casos, puedes usar `root_path` para configurar tu aplicación. |
|||
|
|||
El `root_path` es un mecanismo proporcionado por la especificación ASGI (en la que está construido FastAPI, a través de Starlette). |
|||
|
|||
El `root_path` se usa para manejar estos casos específicos. |
|||
|
|||
Y también se usa internamente al montar subaplicaciones. |
|||
|
|||
## Proxy con un prefijo de path eliminado |
|||
|
|||
Tener un proxy con un prefijo de path eliminado, en este caso, significa que podrías declarar un path en `/app` en tu código, pero luego añades una capa encima (el proxy) que situaría tu aplicación **FastAPI** bajo un path como `/api/v1`. |
|||
|
|||
En este caso, el path original `/app` realmente sería servido en `/api/v1/app`. |
|||
|
|||
Aunque todo tu código esté escrito asumiendo que solo existe `/app`. |
|||
|
|||
{* ../../docs_src/behind_a_proxy/tutorial001.py hl[6] *} |
|||
|
|||
Y el proxy estaría **"eliminando"** el **prefijo del path** sobre la marcha antes de transmitir el request al servidor de aplicaciones (probablemente Uvicorn a través de FastAPI CLI), manteniendo a tu aplicación convencida de que está siendo servida en `/app`, así que no tienes que actualizar todo tu código para incluir el prefijo `/api/v1`. |
|||
|
|||
Hasta aquí, todo funcionaría normalmente. |
|||
|
|||
Pero luego, cuando abres la UI integrada de los docs (el frontend), esperaría obtener el esquema de OpenAPI en `/openapi.json`, en lugar de `/api/v1/openapi.json`. |
|||
|
|||
Entonces, el frontend (que se ejecuta en el navegador) trataría de alcanzar `/openapi.json` y no podría obtener el esquema de OpenAPI. |
|||
|
|||
Porque tenemos un proxy con un prefijo de path de `/api/v1` para nuestra aplicación, el frontend necesita obtener el esquema de OpenAPI en `/api/v1/openapi.json`. |
|||
|
|||
```mermaid |
|||
graph LR |
|||
|
|||
browser("Navegador") |
|||
proxy["Proxy en http://0.0.0.0:9999/api/v1/app"] |
|||
server["Servidor en http://127.0.0.1:8000/app"] |
|||
|
|||
browser --> proxy |
|||
proxy --> server |
|||
``` |
|||
|
|||
/// tip | Consejo |
|||
|
|||
La IP `0.0.0.0` se usa comúnmente para indicar que el programa escucha en todas las IPs disponibles en esa máquina/servidor. |
|||
|
|||
/// |
|||
|
|||
La UI de los docs también necesitaría el esquema de OpenAPI para declarar que este API `servidor` se encuentra en `/api/v1` (detrás del proxy). Por ejemplo: |
|||
|
|||
```JSON hl_lines="4-8" |
|||
{ |
|||
"openapi": "3.1.0", |
|||
// Más cosas aquí |
|||
"servers": [ |
|||
{ |
|||
"url": "/api/v1" |
|||
} |
|||
], |
|||
"paths": { |
|||
// Más cosas aquí |
|||
} |
|||
} |
|||
``` |
|||
|
|||
En este ejemplo, el "Proxy" podría ser algo como **Traefik**. Y el servidor sería algo como FastAPI CLI con **Uvicorn**, ejecutando tu aplicación de FastAPI. |
|||
|
|||
### Proporcionando el `root_path` |
|||
|
|||
Para lograr esto, puedes usar la opción de línea de comandos `--root-path` como: |
|||
|
|||
<div class="termy"> |
|||
|
|||
```console |
|||
$ fastapi run main.py --root-path /api/v1 |
|||
|
|||
<span style="color: green;">INFO</span>: Uvicorn running on http://127.0.0.1:8000 (Press CTRL+C to quit) |
|||
``` |
|||
|
|||
</div> |
|||
|
|||
Si usas Hypercorn, también tiene la opción `--root-path`. |
|||
|
|||
/// note | Detalles Técnicos |
|||
|
|||
La especificación ASGI define un `root_path` para este caso de uso. |
|||
|
|||
Y la opción de línea de comandos `--root-path` proporciona ese `root_path`. |
|||
|
|||
/// |
|||
|
|||
### Revisar el `root_path` actual |
|||
|
|||
Puedes obtener el `root_path` actual utilizado por tu aplicación para cada request, es parte del diccionario `scope` (que es parte de la especificación ASGI). |
|||
|
|||
Aquí lo estamos incluyendo en el mensaje solo con fines de demostración. |
|||
|
|||
{* ../../docs_src/behind_a_proxy/tutorial001.py hl[8] *} |
|||
|
|||
Luego, si inicias Uvicorn con: |
|||
|
|||
<div class="termy"> |
|||
|
|||
```console |
|||
$ fastapi run main.py --root-path /api/v1 |
|||
|
|||
<span style="color: green;">INFO</span>: Uvicorn running on http://127.0.0.1:8000 (Press CTRL+C to quit) |
|||
``` |
|||
|
|||
</div> |
|||
|
|||
El response sería algo como: |
|||
|
|||
```JSON |
|||
{ |
|||
"message": "Hello World", |
|||
"root_path": "/api/v1" |
|||
} |
|||
``` |
|||
|
|||
### Configurar el `root_path` en la app de FastAPI |
|||
|
|||
Alternativamente, si no tienes una forma de proporcionar una opción de línea de comandos como `--root-path` o su equivalente, puedes configurar el parámetro `root_path` al crear tu app de FastAPI: |
|||
|
|||
{* ../../docs_src/behind_a_proxy/tutorial002.py hl[3] *} |
|||
|
|||
Pasar el `root_path` a `FastAPI` sería el equivalente a pasar la opción de línea de comandos `--root-path` a Uvicorn o Hypercorn. |
|||
|
|||
### Acerca de `root_path` |
|||
|
|||
Ten en cuenta que el servidor (Uvicorn) no usará ese `root_path` para nada, a excepción de pasárselo a la app. |
|||
|
|||
Pero si vas con tu navegador a <a href="http://127.0.0.1:8000" class="external-link" target="_blank">http://127.0.0.1:8000/app</a> verás el response normal: |
|||
|
|||
```JSON |
|||
{ |
|||
"message": "Hello World", |
|||
"root_path": "/api/v1" |
|||
} |
|||
``` |
|||
|
|||
Así que no se esperará que sea accedido en `http://127.0.0.1:8000/api/v1/app`. |
|||
|
|||
Uvicorn esperará que el proxy acceda a Uvicorn en `http://127.0.0.1:8000/app`, y luego será responsabilidad del proxy añadir el prefijo extra `/api/v1` encima. |
|||
|
|||
## Sobre proxies con un prefijo de path eliminado |
|||
|
|||
Ten en cuenta que un proxy con prefijo de path eliminado es solo una de las formas de configurarlo. |
|||
|
|||
Probablemente en muchos casos, el valor predeterminado será que el proxy no tenga un prefijo de path eliminado. |
|||
|
|||
En un caso así (sin un prefijo de path eliminado), el proxy escucharía algo como `https://myawesomeapp.com`, y luego si el navegador va a `https://myawesomeapp.com/api/v1/app` y tu servidor (por ejemplo, Uvicorn) escucha en `http://127.0.0.1:8000`, el proxy (sin un prefijo de path eliminado) accedería a Uvicorn en el mismo path: `http://127.0.0.1:8000/api/v1/app`. |
|||
|
|||
## Probando localmente con Traefik |
|||
|
|||
Puedes ejecutar fácilmente el experimento localmente con un prefijo de path eliminado usando <a href="https://docs.traefik.io/" class="external-link" target="_blank">Traefik</a>. |
|||
|
|||
<a href="https://github.com/containous/traefik/releases" class="external-link" target="_blank">Descarga Traefik</a>, es un archivo binario único, puedes extraer el archivo comprimido y ejecutarlo directamente desde la terminal. |
|||
|
|||
Luego crea un archivo `traefik.toml` con: |
|||
|
|||
```TOML hl_lines="3" |
|||
[entryPoints] |
|||
[entryPoints.http] |
|||
address = ":9999" |
|||
|
|||
[providers] |
|||
[providers.file] |
|||
filename = "routes.toml" |
|||
``` |
|||
|
|||
Esto le dice a Traefik que escuche en el puerto 9999 y que use otro archivo `routes.toml`. |
|||
|
|||
/// tip | Consejo |
|||
|
|||
Estamos utilizando el puerto 9999 en lugar del puerto HTTP estándar 80 para que no tengas que ejecutarlo con privilegios de administrador (`sudo`). |
|||
|
|||
/// |
|||
|
|||
Ahora crea ese otro archivo `routes.toml`: |
|||
|
|||
```TOML hl_lines="5 12 20" |
|||
[http] |
|||
[http.middlewares] |
|||
|
|||
[http.middlewares.api-stripprefix.stripPrefix] |
|||
prefixes = ["/api/v1"] |
|||
|
|||
[http.routers] |
|||
|
|||
[http.routers.app-http] |
|||
entryPoints = ["http"] |
|||
service = "app" |
|||
rule = "PathPrefix(`/api/v1`)" |
|||
middlewares = ["api-stripprefix"] |
|||
|
|||
[http.services] |
|||
|
|||
[http.services.app] |
|||
[http.services.app.loadBalancer] |
|||
[[http.services.app.loadBalancer.servers]] |
|||
url = "http://127.0.0.1:8000" |
|||
``` |
|||
|
|||
Este archivo configura Traefik para usar el prefijo de path `/api/v1`. |
|||
|
|||
Y luego Traefik redireccionará sus requests a tu Uvicorn ejecutándose en `http://127.0.0.1:8000`. |
|||
|
|||
Ahora inicia Traefik: |
|||
|
|||
<div class="termy"> |
|||
|
|||
```console |
|||
$ ./traefik --configFile=traefik.toml |
|||
|
|||
INFO[0000] Configuration loaded from file: /home/user/awesomeapi/traefik.toml |
|||
``` |
|||
|
|||
</div> |
|||
|
|||
Y ahora inicia tu app, utilizando la opción `--root-path`: |
|||
|
|||
<div class="termy"> |
|||
|
|||
```console |
|||
$ fastapi run main.py --root-path /api/v1 |
|||
|
|||
<span style="color: green;">INFO</span>: Uvicorn running on http://127.0.0.1:8000 (Press CTRL+C to quit) |
|||
``` |
|||
|
|||
</div> |
|||
|
|||
### Revisa los responses |
|||
|
|||
Ahora, si vas a la URL con el puerto para Uvicorn: <a href="http://127.0.0.1:8000/app" class="external-link" target="_blank">http://127.0.0.1:8000/app</a>, verás el response normal: |
|||
|
|||
```JSON |
|||
{ |
|||
"message": "Hello World", |
|||
"root_path": "/api/v1" |
|||
} |
|||
``` |
|||
|
|||
/// tip | Consejo |
|||
|
|||
Nota que incluso aunque estés accediendo en `http://127.0.0.1:8000/app`, muestra el `root_path` de `/api/v1`, tomado de la opción `--root-path`. |
|||
|
|||
/// |
|||
|
|||
Y ahora abre la URL con el puerto para Traefik, incluyendo el prefijo de path: <a href="http://127.0.0.1:9999/api/v1/app" class="external-link" target="_blank">http://127.0.0.1:9999/api/v1/app</a>. |
|||
|
|||
Obtenemos el mismo response: |
|||
|
|||
```JSON |
|||
{ |
|||
"message": "Hello World", |
|||
"root_path": "/api/v1" |
|||
} |
|||
``` |
|||
|
|||
pero esta vez en la URL con el prefijo de path proporcionado por el proxy: `/api/v1`. |
|||
|
|||
Por supuesto, la idea aquí es que todos accedan a la app a través del proxy, así que la versión con el prefijo de path `/api/v1` es la "correcta". |
|||
|
|||
Y la versión sin el prefijo de path (`http://127.0.0.1:8000/app`), proporcionada directamente por Uvicorn, sería exclusivamente para que el _proxy_ (Traefik) la acceda. |
|||
|
|||
Eso demuestra cómo el Proxy (Traefik) usa el prefijo de path y cómo el servidor (Uvicorn) usa el `root_path` de la opción `--root-path`. |
|||
|
|||
### Revisa la UI de los docs |
|||
|
|||
Pero aquí está la parte divertida. ✨ |
|||
|
|||
La forma "oficial" de acceder a la app sería a través del proxy con el prefijo de path que definimos. Así que, como esperaríamos, si intentas usar la UI de los docs servida por Uvicorn directamente, sin el prefijo de path en la URL, no funcionará, porque espera ser accedida a través del proxy. |
|||
|
|||
Puedes verificarlo en <a href="http://127.0.0.1:8000/docs" class="external-link" target="_blank">http://127.0.0.1:8000/docs</a>: |
|||
|
|||
<img src="/img/tutorial/behind-a-proxy/image01.png"> |
|||
|
|||
Pero si accedemos a la UI de los docs en la URL "oficial" usando el proxy con puerto `9999`, en `/api/v1/docs`, ¡funciona correctamente! 🎉 |
|||
|
|||
Puedes verificarlo en <a href="http://127.0.0.1:9999/api/v1/docs" class="external-link" target="_blank">http://127.0.0.1:9999/api/v1/docs</a>: |
|||
|
|||
<img src="/img/tutorial/behind-a-proxy/image02.png"> |
|||
|
|||
Justo como queríamos. ✔️ |
|||
|
|||
Esto es porque FastAPI usa este `root_path` para crear el `server` por defecto en OpenAPI con la URL proporcionada por `root_path`. |
|||
|
|||
## Servidores adicionales |
|||
|
|||
/// warning | Advertencia |
|||
|
|||
Este es un caso de uso más avanzado. Siéntete libre de omitirlo. |
|||
|
|||
/// |
|||
|
|||
Por defecto, **FastAPI** creará un `server` en el esquema de OpenAPI con la URL para el `root_path`. |
|||
|
|||
Pero también puedes proporcionar otros `servers` alternativos, por ejemplo, si deseas que *la misma* UI de los docs interactúe con un entorno de pruebas y de producción. |
|||
|
|||
Si pasas una lista personalizada de `servers` y hay un `root_path` (porque tu API existe detrás de un proxy), **FastAPI** insertará un "server" con este `root_path` al comienzo de la lista. |
|||
|
|||
Por ejemplo: |
|||
|
|||
{* ../../docs_src/behind_a_proxy/tutorial003.py hl[4:7] *} |
|||
|
|||
Generará un esquema de OpenAPI como: |
|||
|
|||
```JSON hl_lines="5-7" |
|||
{ |
|||
"openapi": "3.1.0", |
|||
// Más cosas aquí |
|||
"servers": [ |
|||
{ |
|||
"url": "/api/v1" |
|||
}, |
|||
{ |
|||
"url": "https://stag.example.com", |
|||
"description": "Entorno de pruebas" |
|||
}, |
|||
{ |
|||
"url": "https://prod.example.com", |
|||
"description": "Entorno de producción" |
|||
} |
|||
], |
|||
"paths": { |
|||
// Más cosas aquí |
|||
} |
|||
} |
|||
``` |
|||
|
|||
/// tip | Consejo |
|||
|
|||
Observa el server auto-generado con un valor `url` de `/api/v1`, tomado del `root_path`. |
|||
|
|||
/// |
|||
|
|||
En la UI de los docs en <a href="http://127.0.0.1:9999/api/v1/docs" class="external-link" target="_blank">http://127.0.0.1:9999/api/v1/docs</a> se vería como: |
|||
|
|||
<img src="/img/tutorial/behind-a-proxy/image03.png"> |
|||
|
|||
/// tip | Consejo |
|||
|
|||
La UI de los docs interactuará con el server que selecciones. |
|||
|
|||
/// |
|||
|
|||
### Desactivar el server automático de `root_path` |
|||
|
|||
Si no quieres que **FastAPI** incluya un server automático usando el `root_path`, puedes usar el parámetro `root_path_in_servers=False`: |
|||
|
|||
{* ../../docs_src/behind_a_proxy/tutorial004.py hl[9] *} |
|||
|
|||
y entonces no lo incluirá en el esquema de OpenAPI. |
|||
|
|||
## Montando una sub-aplicación |
|||
|
|||
Si necesitas montar una sub-aplicación (como se describe en [Aplicaciones secundarias - Monturas](sub-applications.md){.internal-link target=_blank}) mientras usas un proxy con `root_path`, puedes hacerlo normalmente, como esperarías. |
|||
|
|||
FastAPI usará internamente el `root_path` de manera inteligente, así que simplemente funcionará. ✨ |
@ -0,0 +1,312 @@ |
|||
# Response Personalizado - HTML, Stream, Archivo, otros |
|||
|
|||
Por defecto, **FastAPI** devolverá los responses usando `JSONResponse`. |
|||
|
|||
Puedes sobrescribirlo devolviendo un `Response` directamente como se ve en [Devolver una Response directamente](response-directly.md){.internal-link target=_blank}. |
|||
|
|||
Pero si devuelves un `Response` directamente (o cualquier subclase, como `JSONResponse`), los datos no se convertirán automáticamente (incluso si declaras un `response_model`), y la documentación no se generará automáticamente (por ejemplo, incluyendo el "media type" específico, en el HTTP header `Content-Type` como parte del OpenAPI generado). |
|||
|
|||
Pero también puedes declarar el `Response` que quieres usar (por ejemplo, cualquier subclase de `Response`), en el *path operation decorator* usando el parámetro `response_class`. |
|||
|
|||
Los contenidos que devuelvas desde tu *path operation function* se colocarán dentro de esa `Response`. |
|||
|
|||
Y si ese `Response` tiene un media type JSON (`application/json`), como es el caso con `JSONResponse` y `UJSONResponse`, los datos que devuelvas se convertirán automáticamente (y serán filtrados) con cualquier `response_model` de Pydantic que hayas declarado en el *path operation decorator*. |
|||
|
|||
/// note | Nota |
|||
|
|||
Si usas una clase de response sin media type, FastAPI esperará que tu response no tenga contenido, por lo que no documentará el formato del response en su OpenAPI generado. |
|||
|
|||
/// |
|||
|
|||
## Usa `ORJSONResponse` |
|||
|
|||
Por ejemplo, si estás exprimendo el rendimiento, puedes instalar y usar <a href="https://github.com/ijl/orjson" class="external-link" target="_blank">`orjson`</a> y establecer el response como `ORJSONResponse`. |
|||
|
|||
Importa la clase `Response` (sub-clase) que quieras usar y declárala en el *path operation decorator*. |
|||
|
|||
Para responses grandes, devolver una `Response` directamente es mucho más rápido que devolver un diccionario. |
|||
|
|||
Esto se debe a que, por defecto, FastAPI inspeccionará cada elemento dentro y se asegurará de que sea serializable como JSON, usando el mismo [Codificador Compatible con JSON](../tutorial/encoder.md){.internal-link target=_blank} explicado en el tutorial. Esto es lo que te permite devolver **objetos arbitrarios**, por ejemplo, modelos de bases de datos. |
|||
|
|||
Pero si estás seguro de que el contenido que estás devolviendo es **serializable con JSON**, puedes pasarlo directamente a la clase de response y evitar la sobrecarga extra que FastAPI tendría al pasar tu contenido de retorno a través de `jsonable_encoder` antes de pasarlo a la clase de response. |
|||
|
|||
{* ../../docs_src/custom_response/tutorial001b.py hl[2,7] *} |
|||
|
|||
/// info | Información |
|||
|
|||
El parámetro `response_class` también se utilizará para definir el "media type" del response. |
|||
|
|||
En este caso, el HTTP header `Content-Type` se establecerá en `application/json`. |
|||
|
|||
Y se documentará así en OpenAPI. |
|||
|
|||
/// |
|||
|
|||
/// tip | Consejo |
|||
|
|||
El `ORJSONResponse` solo está disponible en FastAPI, no en Starlette. |
|||
|
|||
/// |
|||
|
|||
## Response HTML |
|||
|
|||
Para devolver un response con HTML directamente desde **FastAPI**, usa `HTMLResponse`. |
|||
|
|||
* Importa `HTMLResponse`. |
|||
* Pasa `HTMLResponse` como parámetro `response_class` de tu *path operation decorator*. |
|||
|
|||
{* ../../docs_src/custom_response/tutorial002.py hl[2,7] *} |
|||
|
|||
/// info | Información |
|||
|
|||
El parámetro `response_class` también se utilizará para definir el "media type" del response. |
|||
|
|||
En este caso, el HTTP header `Content-Type` se establecerá en `text/html`. |
|||
|
|||
Y se documentará así en OpenAPI. |
|||
|
|||
/// |
|||
|
|||
### Devuelve una `Response` |
|||
|
|||
Como se ve en [Devolver una Response directamente](response-directly.md){.internal-link target=_blank}, también puedes sobrescribir el response directamente en tu *path operation*, devolviéndolo. |
|||
|
|||
El mismo ejemplo de arriba, devolviendo una `HTMLResponse`, podría verse así: |
|||
|
|||
{* ../../docs_src/custom_response/tutorial003.py hl[2,7,19] *} |
|||
|
|||
/// warning | Advertencia |
|||
|
|||
Una `Response` devuelta directamente por tu *path operation function* no se documentará en OpenAPI (por ejemplo, el `Content-Type` no se documentará) y no será visible en la documentación interactiva automática. |
|||
|
|||
/// |
|||
|
|||
/// info | Información |
|||
|
|||
Por supuesto, el `Content-Type` header real, el código de estado, etc., provendrán del objeto `Response` que devolviste. |
|||
|
|||
/// |
|||
|
|||
### Documenta en OpenAPI y sobrescribe `Response` |
|||
|
|||
Si quieres sobrescribir el response desde dentro de la función pero al mismo tiempo documentar el "media type" en OpenAPI, puedes usar el parámetro `response_class` Y devolver un objeto `Response`. |
|||
|
|||
El `response_class` solo se usará para documentar el OpenAPI *path operation*, pero tu `Response` se usará tal cual. |
|||
|
|||
#### Devuelve un `HTMLResponse` directamente |
|||
|
|||
Por ejemplo, podría ser algo así: |
|||
|
|||
{* ../../docs_src/custom_response/tutorial004.py hl[7,21,23] *} |
|||
|
|||
En este ejemplo, la función `generate_html_response()` ya genera y devuelve una `Response` en lugar de devolver el HTML en un `str`. |
|||
|
|||
Al devolver el resultado de llamar a `generate_html_response()`, ya estás devolviendo una `Response` que sobrescribirá el comportamiento predeterminado de **FastAPI**. |
|||
|
|||
Pero como pasaste `HTMLResponse` en el `response_class` también, **FastAPI** sabrá cómo documentarlo en OpenAPI y la documentación interactiva como HTML con `text/html`: |
|||
|
|||
<img src="/img/tutorial/custom-response/image01.png"> |
|||
|
|||
## Responses disponibles |
|||
|
|||
Aquí hay algunos de los responses disponibles. |
|||
|
|||
Ten en cuenta que puedes usar `Response` para devolver cualquier otra cosa, o incluso crear una sub-clase personalizada. |
|||
|
|||
/// note | Nota Técnica |
|||
|
|||
También podrías usar `from starlette.responses import HTMLResponse`. |
|||
|
|||
**FastAPI** proporciona los mismos `starlette.responses` como `fastapi.responses` solo como una conveniencia para ti, el desarrollador. Pero la mayoría de los responses disponibles vienen directamente de Starlette. |
|||
|
|||
/// |
|||
|
|||
### `Response` |
|||
|
|||
La clase principal `Response`, todos los otros responses heredan de ella. |
|||
|
|||
Puedes devolverla directamente. |
|||
|
|||
Acepta los siguientes parámetros: |
|||
|
|||
* `content` - Un `str` o `bytes`. |
|||
* `status_code` - Un código de estado HTTP `int`. |
|||
* `headers` - Un `dict` de strings. |
|||
* `media_type` - Un `str` que da el media type. Por ejemplo, `"text/html"`. |
|||
|
|||
FastAPI (de hecho Starlette) incluirá automáticamente un header Content-Length. También incluirá un header Content-Type, basado en el `media_type` y añadiendo un conjunto de caracteres para tipos de texto. |
|||
|
|||
{* ../../docs_src/response_directly/tutorial002.py hl[1,18] *} |
|||
|
|||
### `HTMLResponse` |
|||
|
|||
Toma algún texto o bytes y devuelve un response HTML, como leíste arriba. |
|||
|
|||
### `PlainTextResponse` |
|||
|
|||
Toma algún texto o bytes y devuelve un response de texto plano. |
|||
|
|||
{* ../../docs_src/custom_response/tutorial005.py hl[2,7,9] *} |
|||
|
|||
### `JSONResponse` |
|||
|
|||
Toma algunos datos y devuelve un response codificado como `application/json`. |
|||
|
|||
Este es el response predeterminado usado en **FastAPI**, como leíste arriba. |
|||
|
|||
### `ORJSONResponse` |
|||
|
|||
Un response JSON rápido alternativo usando <a href="https://github.com/ijl/orjson" class="external-link" target="_blank">`orjson`</a>, como leíste arriba. |
|||
|
|||
/// info | Información |
|||
|
|||
Esto requiere instalar `orjson`, por ejemplo, con `pip install orjson`. |
|||
|
|||
/// |
|||
|
|||
### `UJSONResponse` |
|||
|
|||
Un response JSON alternativo usando <a href="https://github.com/ultrajson/ultrajson" class="external-link" target="_blank">`ujson`</a>. |
|||
|
|||
/// info | Información |
|||
|
|||
Esto requiere instalar `ujson`, por ejemplo, con `pip install ujson`. |
|||
|
|||
/// |
|||
|
|||
/// warning | Advertencia |
|||
|
|||
`ujson` es menos cuidadoso que la implementación integrada de Python en cómo maneja algunos casos extremos. |
|||
|
|||
/// |
|||
|
|||
{* ../../docs_src/custom_response/tutorial001.py hl[2,7] *} |
|||
|
|||
/// tip | Consejo |
|||
|
|||
Es posible que `ORJSONResponse` sea una alternativa más rápida. |
|||
|
|||
/// |
|||
|
|||
### `RedirectResponse` |
|||
|
|||
Devuelve una redirección HTTP. Usa un código de estado 307 (Redirección Temporal) por defecto. |
|||
|
|||
Puedes devolver un `RedirectResponse` directamente: |
|||
|
|||
{* ../../docs_src/custom_response/tutorial006.py hl[2,9] *} |
|||
|
|||
--- |
|||
|
|||
O puedes usarlo en el parámetro `response_class`: |
|||
|
|||
{* ../../docs_src/custom_response/tutorial006b.py hl[2,7,9] *} |
|||
|
|||
Si haces eso, entonces puedes devolver la URL directamente desde tu *path operation function*. |
|||
|
|||
En este caso, el `status_code` utilizado será el predeterminado para `RedirectResponse`, que es `307`. |
|||
|
|||
--- |
|||
|
|||
También puedes usar el parámetro `status_code` combinado con el parámetro `response_class`: |
|||
|
|||
{* ../../docs_src/custom_response/tutorial006c.py hl[2,7,9] *} |
|||
|
|||
### `StreamingResponse` |
|||
|
|||
Toma un generador `async` o un generador/iterador normal y transmite el cuerpo del response. |
|||
|
|||
{* ../../docs_src/custom_response/tutorial007.py hl[2,14] *} |
|||
|
|||
#### Usando `StreamingResponse` con objetos similares a archivos |
|||
|
|||
Si tienes un objeto similar a un archivo (por ejemplo, el objeto devuelto por `open()`), puedes crear una función generadora para iterar sobre ese objeto similar a un archivo. |
|||
|
|||
De esa manera, no tienes que leerlo todo primero en memoria, y puedes pasar esa función generadora al `StreamingResponse`, y devolverlo. |
|||
|
|||
Esto incluye muchos paquetes para interactuar con almacenamiento en la nube, procesamiento de video y otros. |
|||
|
|||
{* ../../docs_src/custom_response/tutorial008.py hl[2,10:12,14] *} |
|||
|
|||
1. Esta es la función generadora. Es una "función generadora" porque contiene declaraciones `yield` dentro. |
|||
2. Al usar un bloque `with`, nos aseguramos de que el objeto similar a un archivo se cierre después de que la función generadora termine. Así, después de que termina de enviar el response. |
|||
3. Este `yield from` le dice a la función que itere sobre esa cosa llamada `file_like`. Y luego, para cada parte iterada, yield esa parte como proveniente de esta función generadora (`iterfile`). |
|||
|
|||
Entonces, es una función generadora que transfiere el trabajo de "generar" a algo más internamente. |
|||
|
|||
Al hacerlo de esta manera, podemos ponerlo en un bloque `with`, y de esa manera, asegurarnos de que el objeto similar a un archivo se cierre después de finalizar. |
|||
|
|||
/// tip | Consejo |
|||
|
|||
Nota que aquí como estamos usando `open()` estándar que no admite `async` y `await`, declaramos el path operation con `def` normal. |
|||
|
|||
/// |
|||
|
|||
### `FileResponse` |
|||
|
|||
Transmite un archivo asincrónicamente como response. |
|||
|
|||
Toma un conjunto diferente de argumentos para crear un instance que los otros tipos de response: |
|||
|
|||
* `path` - La path del archivo para el archivo a transmitir. |
|||
* `headers` - Cualquier header personalizado para incluir, como un diccionario. |
|||
* `media_type` - Un string que da el media type. Si no se establece, se usará el nombre de archivo o la path para inferir un media type. |
|||
* `filename` - Si se establece, se incluirá en el response `Content-Disposition`. |
|||
|
|||
Los responses de archivos incluirán los headers apropiados `Content-Length`, `Last-Modified` y `ETag`. |
|||
|
|||
{* ../../docs_src/custom_response/tutorial009.py hl[2,10] *} |
|||
|
|||
También puedes usar el parámetro `response_class`: |
|||
|
|||
{* ../../docs_src/custom_response/tutorial009b.py hl[2,8,10] *} |
|||
|
|||
En este caso, puedes devolver la path del archivo directamente desde tu *path operation* function. |
|||
|
|||
## Clase de response personalizada |
|||
|
|||
Puedes crear tu propia clase de response personalizada, heredando de `Response` y usándola. |
|||
|
|||
Por ejemplo, digamos que quieres usar <a href="https://github.com/ijl/orjson" class="external-link" target="_blank">`orjson`</a>, pero con algunas configuraciones personalizadas no utilizadas en la clase `ORJSONResponse` incluida. |
|||
|
|||
Digamos que quieres que devuelva JSON con sangría y formato, por lo que quieres usar la opción de orjson `orjson.OPT_INDENT_2`. |
|||
|
|||
Podrías crear un `CustomORJSONResponse`. Lo principal que tienes que hacer es crear un método `Response.render(content)` que devuelva el contenido como `bytes`: |
|||
|
|||
{* ../../docs_src/custom_response/tutorial009c.py hl[9:14,17] *} |
|||
|
|||
Ahora en lugar de devolver: |
|||
|
|||
```json |
|||
{"message": "Hello World"} |
|||
``` |
|||
|
|||
...este response devolverá: |
|||
|
|||
```json |
|||
{ |
|||
"message": "Hello World" |
|||
} |
|||
``` |
|||
|
|||
Por supuesto, probablemente encontrarás formas mucho mejores de aprovechar esto que formatear JSON. 😉 |
|||
|
|||
## Clase de response predeterminada |
|||
|
|||
Al crear una instance de la clase **FastAPI** o un `APIRouter`, puedes especificar qué clase de response usar por defecto. |
|||
|
|||
El parámetro que define esto es `default_response_class`. |
|||
|
|||
En el ejemplo a continuación, **FastAPI** usará `ORJSONResponse` por defecto, en todas las *path operations*, en lugar de `JSONResponse`. |
|||
|
|||
{* ../../docs_src/custom_response/tutorial010.py hl[2,4] *} |
|||
|
|||
/// tip | Consejo |
|||
|
|||
Todavía puedes sobrescribir `response_class` en *path operations* como antes. |
|||
|
|||
/// |
|||
|
|||
## Documentación adicional |
|||
|
|||
También puedes declarar el media type y muchos otros detalles en OpenAPI usando `responses`: [Responses Adicionales en OpenAPI](additional-responses.md){.internal-link target=_blank}. |
@ -0,0 +1,95 @@ |
|||
# Usando Dataclasses |
|||
|
|||
FastAPI está construido sobre **Pydantic**, y te he estado mostrando cómo usar modelos de Pydantic para declarar requests y responses. |
|||
|
|||
Pero FastAPI también soporta el uso de <a href="https://docs.python.org/3/library/dataclasses.html" class="external-link" target="_blank">`dataclasses`</a> de la misma manera: |
|||
|
|||
{* ../../docs_src/dataclasses/tutorial001.py hl[1,7:12,19:20] *} |
|||
|
|||
Esto sigue siendo soportado gracias a **Pydantic**, ya que tiene <a href="https://docs.pydantic.dev/latest/concepts/dataclasses/#use-of-stdlib-dataclasses-with-basemodel" class="external-link" target="_blank">soporte interno para `dataclasses`</a>. |
|||
|
|||
Así que, incluso con el código anterior que no usa Pydantic explícitamente, FastAPI está usando Pydantic para convertir esos dataclasses estándar en su propia versión de dataclasses de Pydantic. |
|||
|
|||
Y por supuesto, soporta lo mismo: |
|||
|
|||
* validación de datos |
|||
* serialización de datos |
|||
* documentación de datos, etc. |
|||
|
|||
Esto funciona de la misma manera que con los modelos de Pydantic. Y en realidad se logra de la misma manera internamente, utilizando Pydantic. |
|||
|
|||
/// info | Información |
|||
|
|||
Ten en cuenta que los dataclasses no pueden hacer todo lo que los modelos de Pydantic pueden hacer. |
|||
|
|||
Así que, podrías necesitar seguir usando modelos de Pydantic. |
|||
|
|||
Pero si tienes un montón de dataclasses por ahí, este es un buen truco para usarlos para potenciar una API web usando FastAPI. 🤓 |
|||
|
|||
/// |
|||
|
|||
## Dataclasses en `response_model` |
|||
|
|||
También puedes usar `dataclasses` en el parámetro `response_model`: |
|||
|
|||
{* ../../docs_src/dataclasses/tutorial002.py hl[1,7:13,19] *} |
|||
|
|||
El dataclass será automáticamente convertido a un dataclass de Pydantic. |
|||
|
|||
De esta manera, su esquema aparecerá en la interfaz de usuario de la documentación de la API: |
|||
|
|||
<img src="/img/tutorial/dataclasses/image01.png"> |
|||
|
|||
## Dataclasses en Estructuras de Datos Anidadas |
|||
|
|||
También puedes combinar `dataclasses` con otras anotaciones de tipos para crear estructuras de datos anidadas. |
|||
|
|||
En algunos casos, todavía podrías tener que usar la versión de `dataclasses` de Pydantic. Por ejemplo, si tienes errores con la documentación de la API generada automáticamente. |
|||
|
|||
En ese caso, simplemente puedes intercambiar los `dataclasses` estándar con `pydantic.dataclasses`, que es un reemplazo directo: |
|||
|
|||
{* ../../docs_src/dataclasses/tutorial003.py hl[1,5,8:11,14:17,23:25,28] *} |
|||
|
|||
1. Todavía importamos `field` de los `dataclasses` estándar. |
|||
|
|||
2. `pydantic.dataclasses` es un reemplazo directo para `dataclasses`. |
|||
|
|||
3. El dataclass `Author` incluye una lista de dataclasses `Item`. |
|||
|
|||
4. El dataclass `Author` se usa como el parámetro `response_model`. |
|||
|
|||
5. Puedes usar otras anotaciones de tipos estándar con dataclasses como el request body. |
|||
|
|||
En este caso, es una lista de dataclasses `Item`. |
|||
|
|||
6. Aquí estamos regresando un diccionario que contiene `items`, que es una lista de dataclasses. |
|||
|
|||
FastAPI todavía es capaz de <abbr title="converting the data to a format that can be transmitted">serializar</abbr> los datos a JSON. |
|||
|
|||
7. Aquí el `response_model` está usando una anotación de tipo de una lista de dataclasses `Author`. |
|||
|
|||
Nuevamente, puedes combinar `dataclasses` con anotaciones de tipos estándar. |
|||
|
|||
8. Nota que esta *path operation function* usa `def` regular en lugar de `async def`. |
|||
|
|||
Como siempre, en FastAPI puedes combinar `def` y `async def` según sea necesario. |
|||
|
|||
Si necesitas un repaso sobre cuándo usar cuál, revisa la sección _"¿Con prisa?"_ en la documentación sobre [`async` y `await`](../async.md#in-a-hurry){.internal-link target=_blank}. |
|||
|
|||
9. Esta *path operation function* no está devolviendo dataclasses (aunque podría), sino una lista de diccionarios con datos internos. |
|||
|
|||
FastAPI usará el parámetro `response_model` (que incluye dataclasses) para convertir el response. |
|||
|
|||
Puedes combinar `dataclasses` con otras anotaciones de tipos en muchas combinaciones diferentes para formar estructuras de datos complejas. |
|||
|
|||
Revisa las anotaciones en el código arriba para ver más detalles específicos. |
|||
|
|||
## Aprende Más |
|||
|
|||
También puedes combinar `dataclasses` con otros modelos de Pydantic, heredar de ellos, incluirlos en tus propios modelos, etc. |
|||
|
|||
Para saber más, revisa la <a href="https://docs.pydantic.dev/latest/concepts/dataclasses/" class="external-link" target="_blank">documentación de Pydantic sobre dataclasses</a>. |
|||
|
|||
## Versión |
|||
|
|||
Esto está disponible desde la versión `0.67.0` de FastAPI. 🔖 |
@ -0,0 +1,165 @@ |
|||
# Eventos de Lifespan |
|||
|
|||
Puedes definir lógica (código) que debería ser ejecutada antes de que la aplicación **inicie**. Esto significa que este código será ejecutado **una vez**, **antes** de que la aplicación **comience a recibir requests**. |
|||
|
|||
De la misma manera, puedes definir lógica (código) que debería ser ejecutada cuando la aplicación esté **cerrándose**. En este caso, este código será ejecutado **una vez**, **después** de haber manejado posiblemente **muchos requests**. |
|||
|
|||
Debido a que este código se ejecuta antes de que la aplicación **comience** a tomar requests, y justo después de que **termine** de manejarlos, cubre todo el **lifespan** de la aplicación (la palabra "lifespan" será importante en un momento 😉). |
|||
|
|||
Esto puede ser muy útil para configurar **recursos** que necesitas usar para toda la app, y que son **compartidos** entre requests, y/o que necesitas **limpiar** después. Por ejemplo, un pool de conexiones a una base de datos, o cargando un modelo de machine learning compartido. |
|||
|
|||
## Caso de Uso |
|||
|
|||
Empecemos con un ejemplo de **caso de uso** y luego veamos cómo resolverlo con esto. |
|||
|
|||
Imaginemos que tienes algunos **modelos de machine learning** que quieres usar para manejar requests. 🤖 |
|||
|
|||
Los mismos modelos son compartidos entre requests, por lo que no es un modelo por request, o uno por usuario o algo similar. |
|||
|
|||
Imaginemos que cargar el modelo puede **tomar bastante tiempo**, porque tiene que leer muchos **datos del disco**. Entonces no quieres hacerlo para cada request. |
|||
|
|||
Podrías cargarlo en el nivel superior del módulo/archivo, pero eso también significaría que **cargaría el modelo** incluso si solo estás ejecutando una simple prueba automatizada, entonces esa prueba sería **lenta** porque tendría que esperar a que el modelo se cargue antes de poder ejecutar una parte independiente del código. |
|||
|
|||
Eso es lo que resolveremos, vamos a cargar el modelo antes de que los requests sean manejados, pero solo justo antes de que la aplicación comience a recibir requests, no mientras el código se está cargando. |
|||
|
|||
## Lifespan |
|||
|
|||
Puedes definir esta lógica de *startup* y *shutdown* usando el parámetro `lifespan` de la app de `FastAPI`, y un "context manager" (te mostraré lo que es en un momento). |
|||
|
|||
Comencemos con un ejemplo y luego veámoslo en detalle. |
|||
|
|||
Creamos una función asíncrona `lifespan()` con `yield` así: |
|||
|
|||
{* ../../docs_src/events/tutorial003.py hl[16,19] *} |
|||
|
|||
Aquí estamos simulando la operación costosa de *startup* de cargar el modelo poniendo la función del (falso) modelo en el diccionario con modelos de machine learning antes del `yield`. Este código será ejecutado **antes** de que la aplicación **comience a tomar requests**, durante el *startup*. |
|||
|
|||
Y luego, justo después del `yield`, quitaremos el modelo de memoria. Este código será ejecutado **después** de que la aplicación **termine de manejar requests**, justo antes del *shutdown*. Esto podría, por ejemplo, liberar recursos como la memoria o una GPU. |
|||
|
|||
/// tip | Consejo |
|||
|
|||
El `shutdown` ocurriría cuando estás **deteniendo** la aplicación. |
|||
|
|||
Quizás necesites iniciar una nueva versión, o simplemente te cansaste de ejecutarla. 🤷 |
|||
|
|||
/// |
|||
|
|||
### Función de Lifespan |
|||
|
|||
Lo primero que hay que notar es que estamos definiendo una función asíncrona con `yield`. Esto es muy similar a las Dependencias con `yield`. |
|||
|
|||
{* ../../docs_src/events/tutorial003.py hl[14:19] *} |
|||
|
|||
La primera parte de la función, antes del `yield`, será ejecutada **antes** de que la aplicación comience. |
|||
|
|||
Y la parte después del `yield` será ejecutada **después** de que la aplicación haya terminado. |
|||
|
|||
### Async Context Manager |
|||
|
|||
Si revisas, la función está decorada con un `@asynccontextmanager`. |
|||
|
|||
Eso convierte a la función en algo llamado un "**async context manager**". |
|||
|
|||
{* ../../docs_src/events/tutorial003.py hl[1,13] *} |
|||
|
|||
Un **context manager** en Python es algo que puedes usar en una declaración `with`, por ejemplo, `open()` puede ser usado como un context manager: |
|||
|
|||
```Python |
|||
with open("file.txt") as file: |
|||
file.read() |
|||
``` |
|||
|
|||
En versiones recientes de Python, también hay un **async context manager**. Lo usarías con `async with`: |
|||
|
|||
```Python |
|||
async with lifespan(app): |
|||
await do_stuff() |
|||
``` |
|||
|
|||
Cuando creas un context manager o un async context manager como arriba, lo que hace es que, antes de entrar al bloque `with`, ejecutará el código antes del `yield`, y al salir del bloque `with`, ejecutará el código después del `yield`. |
|||
|
|||
En nuestro ejemplo de código arriba, no lo usamos directamente, pero se lo pasamos a FastAPI para que lo use. |
|||
|
|||
El parámetro `lifespan` de la app de `FastAPI` toma un **async context manager**, por lo que podemos pasar nuestro nuevo `lifespan` async context manager a él. |
|||
|
|||
{* ../../docs_src/events/tutorial003.py hl[22] *} |
|||
|
|||
## Eventos Alternativos (obsoleto) |
|||
|
|||
/// warning | Advertencia |
|||
|
|||
La forma recomendada de manejar el *startup* y el *shutdown* es usando el parámetro `lifespan` de la app de `FastAPI` como se describió arriba. Si proporcionas un parámetro `lifespan`, los manejadores de eventos `startup` y `shutdown` ya no serán llamados. Es solo `lifespan` o solo los eventos, no ambos. |
|||
|
|||
Probablemente puedas saltarte esta parte. |
|||
|
|||
/// |
|||
|
|||
Hay una forma alternativa de definir esta lógica para ser ejecutada durante el *startup* y durante el *shutdown*. |
|||
|
|||
Puedes definir manejadores de eventos (funciones) que necesitan ser ejecutadas antes de que la aplicación se inicie, o cuando la aplicación se está cerrando. |
|||
|
|||
Estas funciones pueden ser declaradas con `async def` o `def` normal. |
|||
|
|||
### Evento `startup` |
|||
|
|||
Para añadir una función que debería ejecutarse antes de que la aplicación inicie, declárala con el evento `"startup"`: |
|||
|
|||
{* ../../docs_src/events/tutorial001.py hl[8] *} |
|||
|
|||
En este caso, la función manejadora del evento `startup` inicializará los ítems de la "base de datos" (solo un `dict`) con algunos valores. |
|||
|
|||
Puedes añadir más de un manejador de eventos. |
|||
|
|||
Y tu aplicación no comenzará a recibir requests hasta que todos los manejadores de eventos `startup` hayan completado. |
|||
|
|||
### Evento `shutdown` |
|||
|
|||
Para añadir una función que debería ejecutarse cuando la aplicación se esté cerrando, declárala con el evento `"shutdown"`: |
|||
|
|||
{* ../../docs_src/events/tutorial002.py hl[6] *} |
|||
|
|||
Aquí, la función manejadora del evento `shutdown` escribirá una línea de texto `"Application shutdown"` a un archivo `log.txt`. |
|||
|
|||
/// info | Información |
|||
|
|||
En la función `open()`, el `mode="a"` significa "añadir", por lo tanto, la línea será añadida después de lo que sea que esté en ese archivo, sin sobrescribir el contenido anterior. |
|||
|
|||
/// |
|||
|
|||
/// tip | Consejo |
|||
|
|||
Nota que en este caso estamos usando una función estándar de Python `open()` que interactúa con un archivo. |
|||
|
|||
Entonces, involucra I/O (entrada/salida), que requiere "esperar" para que las cosas se escriban en el disco. |
|||
|
|||
Pero `open()` no usa `async` y `await`. |
|||
|
|||
Por eso, declaramos la función manejadora del evento con `def` estándar en vez de `async def`. |
|||
|
|||
/// |
|||
|
|||
### `startup` y `shutdown` juntos |
|||
|
|||
Hay una gran posibilidad de que la lógica para tu *startup* y *shutdown* esté conectada, podrías querer iniciar algo y luego finalizarlo, adquirir un recurso y luego liberarlo, etc. |
|||
|
|||
Hacer eso en funciones separadas que no comparten lógica o variables juntas es más difícil ya que necesitarías almacenar valores en variables globales o trucos similares. |
|||
|
|||
Debido a eso, ahora se recomienda en su lugar usar el `lifespan` como se explicó arriba. |
|||
|
|||
## Detalles Técnicos |
|||
|
|||
Solo un detalle técnico para los nerds curiosos. 🤓 |
|||
|
|||
Por debajo, en la especificación técnica ASGI, esto es parte del <a href="https://asgi.readthedocs.io/en/latest/specs/lifespan.html" class="external-link" target="_blank">Protocolo de Lifespan</a>, y define eventos llamados `startup` y `shutdown`. |
|||
|
|||
/// info | Información |
|||
|
|||
Puedes leer más sobre los manejadores `lifespan` de Starlette en <a href="https://www.starlette.io/lifespan/" class="external-link" target="_blank">la documentación de `Lifespan` de Starlette</a>. |
|||
|
|||
Incluyendo cómo manejar el estado de lifespan que puede ser usado en otras áreas de tu código. |
|||
|
|||
/// |
|||
|
|||
## Sub Aplicaciones |
|||
|
|||
🚨 Ten en cuenta que estos eventos de lifespan (startup y shutdown) solo serán ejecutados para la aplicación principal, no para [Sub Aplicaciones - Mounts](sub-applications.md){.internal-link target=_blank}. |
@ -0,0 +1,261 @@ |
|||
# Genera Clientes |
|||
|
|||
Como **FastAPI** está basado en la especificación OpenAPI, obtienes compatibilidad automática con muchas herramientas, incluyendo la documentación automática de la API (proporcionada por Swagger UI). |
|||
|
|||
Una ventaja particular que no es necesariamente obvia es que puedes **generar clientes** (a veces llamados <abbr title="Software Development Kits">**SDKs**</abbr> ) para tu API, para muchos **lenguajes de programación** diferentes. |
|||
|
|||
## Generadores de Clientes OpenAPI |
|||
|
|||
Hay muchas herramientas para generar clientes desde **OpenAPI**. |
|||
|
|||
Una herramienta común es <a href="https://openapi-generator.tech/" class="external-link" target="_blank">OpenAPI Generator</a>. |
|||
|
|||
Si estás construyendo un **frontend**, una alternativa muy interesante es <a href="https://github.com/hey-api/openapi-ts" class="external-link" target="_blank">openapi-ts</a>. |
|||
|
|||
## Generadores de Clientes y SDKs - Sponsor |
|||
|
|||
También hay algunos generadores de Clientes y SDKs **respaldados por empresas** basados en OpenAPI (FastAPI), en algunos casos pueden ofrecerte **funcionalidades adicionales** además de SDKs/clientes generados de alta calidad. |
|||
|
|||
Algunos de ellos también ✨ [**sponsorean FastAPI**](../help-fastapi.md#sponsor-the-author){.internal-link target=_blank} ✨, esto asegura el **desarrollo** continuo y saludable de FastAPI y su **ecosistema**. |
|||
|
|||
Y muestra su verdadero compromiso con FastAPI y su **comunidad** (tú), ya que no solo quieren proporcionarte un **buen servicio** sino también asegurarse de que tengas un **buen y saludable framework**, FastAPI. 🙇 |
|||
|
|||
Por ejemplo, podrías querer probar: |
|||
|
|||
* <a href="https://speakeasy.com/?utm_source=fastapi+repo&utm_medium=github+sponsorship" class="external-link" target="_blank">Speakeasy</a> |
|||
* <a href="https://www.stainlessapi.com/?utm_source=fastapi&utm_medium=referral" class="external-link" target="_blank">Stainless</a> |
|||
* <a href="https://developers.liblab.com/tutorials/sdk-for-fastapi/?utm_source=fastapi" class="external-link" target="_blank">liblab</a> |
|||
|
|||
También hay varias otras empresas que ofrecen servicios similares que puedes buscar y encontrar en línea. 🤓 |
|||
|
|||
## Genera un Cliente Frontend en TypeScript |
|||
|
|||
Empecemos con una aplicación simple de FastAPI: |
|||
|
|||
{* ../../docs_src/generate_clients/tutorial001_py39.py hl[7:9,12:13,16:17,21] *} |
|||
|
|||
Nota que las *path operations* definen los modelos que usan para el payload de la petición y el payload del response, usando los modelos `Item` y `ResponseMessage`. |
|||
|
|||
### Documentación de la API |
|||
|
|||
Si vas a la documentación de la API, verás que tiene los **esquemas** para los datos que se enviarán en las peticiones y se recibirán en los responses: |
|||
|
|||
<img src="/img/tutorial/generate-clients/image01.png"> |
|||
|
|||
Puedes ver esos esquemas porque fueron declarados con los modelos en la aplicación. |
|||
|
|||
Esa información está disponible en el **JSON Schema** de OpenAPI de la aplicación, y luego se muestra en la documentación de la API (por Swagger UI). |
|||
|
|||
Y esa misma información de los modelos que está incluida en OpenAPI es lo que puede usarse para **generar el código del cliente**. |
|||
|
|||
### Genera un Cliente en TypeScript |
|||
|
|||
Ahora que tenemos la aplicación con los modelos, podemos generar el código del cliente para el frontend. |
|||
|
|||
#### Instalar `openapi-ts` |
|||
|
|||
Puedes instalar `openapi-ts` en tu código de frontend con: |
|||
|
|||
<div class="termy"> |
|||
|
|||
```console |
|||
$ npm install @hey-api/openapi-ts --save-dev |
|||
|
|||
---> 100% |
|||
``` |
|||
|
|||
</div> |
|||
|
|||
#### Generar el Código del Cliente |
|||
|
|||
Para generar el código del cliente puedes usar la aplicación de línea de comandos `openapi-ts` que ahora estaría instalada. |
|||
|
|||
Como está instalada en el proyecto local, probablemente no podrías llamar a ese comando directamente, pero podrías ponerlo en tu archivo `package.json`. |
|||
|
|||
Podría verse como esto: |
|||
|
|||
```JSON hl_lines="7" |
|||
{ |
|||
"name": "frontend-app", |
|||
"version": "1.0.0", |
|||
"description": "", |
|||
"main": "index.js", |
|||
"scripts": { |
|||
"generate-client": "openapi-ts --input http://localhost:8000/openapi.json --output ./src/client --client axios" |
|||
}, |
|||
"author": "", |
|||
"license": "", |
|||
"devDependencies": { |
|||
"@hey-api/openapi-ts": "^0.27.38", |
|||
"typescript": "^4.6.2" |
|||
} |
|||
} |
|||
``` |
|||
|
|||
Después de tener ese script de NPM `generate-client` allí, puedes ejecutarlo con: |
|||
|
|||
<div class="termy"> |
|||
|
|||
```console |
|||
$ npm run generate-client |
|||
|
|||
[email protected] generate-client /home/user/code/frontend-app |
|||
> openapi-ts --input http://localhost:8000/openapi.json --output ./src/client --client axios |
|||
``` |
|||
|
|||
</div> |
|||
|
|||
Ese comando generará código en `./src/client` y usará `axios` (el paquete HTTP de frontend) internamente. |
|||
|
|||
### Prueba el Código del Cliente |
|||
|
|||
Ahora puedes importar y usar el código del cliente, podría verse así, nota que tienes autocompletado para los métodos: |
|||
|
|||
<img src="/img/tutorial/generate-clients/image02.png"> |
|||
|
|||
También obtendrás autocompletado para el payload a enviar: |
|||
|
|||
<img src="/img/tutorial/generate-clients/image03.png"> |
|||
|
|||
/// tip | Consejo |
|||
|
|||
Nota el autocompletado para `name` y `price`, que fue definido en la aplicación de FastAPI, en el modelo `Item`. |
|||
|
|||
/// |
|||
|
|||
Tendrás errores en línea para los datos que envíes: |
|||
|
|||
<img src="/img/tutorial/generate-clients/image04.png"> |
|||
|
|||
El objeto de response también tendrá autocompletado: |
|||
|
|||
<img src="/img/tutorial/generate-clients/image05.png"> |
|||
|
|||
## App de FastAPI con Tags |
|||
|
|||
En muchos casos tu aplicación de FastAPI será más grande, y probablemente usarás tags para separar diferentes grupos de *path operations*. |
|||
|
|||
Por ejemplo, podrías tener una sección para **items** y otra sección para **usuarios**, y podrían estar separadas por tags: |
|||
|
|||
{* ../../docs_src/generate_clients/tutorial002_py39.py hl[21,26,34] *} |
|||
|
|||
### Genera un Cliente TypeScript con Tags |
|||
|
|||
Si generas un cliente para una aplicación de FastAPI usando tags, normalmente también separará el código del cliente basándose en los tags. |
|||
|
|||
De esta manera podrás tener las cosas ordenadas y agrupadas correctamente para el código del cliente: |
|||
|
|||
<img src="/img/tutorial/generate-clients/image06.png"> |
|||
|
|||
En este caso tienes: |
|||
|
|||
* `ItemsService` |
|||
* `UsersService` |
|||
|
|||
### Nombres de los Métodos del Cliente |
|||
|
|||
Ahora mismo los nombres de los métodos generados como `createItemItemsPost` no se ven muy limpios: |
|||
|
|||
```TypeScript |
|||
ItemsService.createItemItemsPost({name: "Plumbus", price: 5}) |
|||
``` |
|||
|
|||
...eso es porque el generador del cliente usa el **operation ID** interno de OpenAPI para cada *path operation*. |
|||
|
|||
OpenAPI requiere que cada operation ID sea único a través de todas las *path operations*, por lo que FastAPI usa el **nombre de la función**, el **path**, y el **método/operación HTTP** para generar ese operation ID, porque de esa manera puede asegurarse de que los operation IDs sean únicos. |
|||
|
|||
Pero te mostraré cómo mejorar eso a continuación. 🤓 |
|||
|
|||
## Operation IDs Personalizados y Mejores Nombres de Métodos |
|||
|
|||
Puedes **modificar** la forma en que estos operation IDs son **generados** para hacerlos más simples y tener **nombres de métodos más simples** en los clientes. |
|||
|
|||
En este caso tendrás que asegurarte de que cada operation ID sea **único** de alguna otra manera. |
|||
|
|||
Por ejemplo, podrías asegurarte de que cada *path operation* tenga un tag, y luego generar el operation ID basado en el **tag** y el nombre de la *path operation* **name** (el nombre de la función). |
|||
|
|||
### Función Personalizada para Generar ID Único |
|||
|
|||
FastAPI usa un **ID único** para cada *path operation*, se usa para el **operation ID** y también para los nombres de cualquier modelo personalizado necesario, para requests o responses. |
|||
|
|||
Puedes personalizar esa función. Toma un `APIRoute` y retorna un string. |
|||
|
|||
Por ejemplo, aquí está usando el primer tag (probablemente tendrás solo un tag) y el nombre de la *path operation* (el nombre de la función). |
|||
|
|||
Puedes entonces pasar esa función personalizada a **FastAPI** como el parámetro `generate_unique_id_function`: |
|||
|
|||
{* ../../docs_src/generate_clients/tutorial003_py39.py hl[6:7,10] *} |
|||
|
|||
### Generar un Cliente TypeScript con Operation IDs Personalizados |
|||
|
|||
Ahora si generas el cliente de nuevo, verás que tiene los nombres de métodos mejorados: |
|||
|
|||
<img src="/img/tutorial/generate-clients/image07.png"> |
|||
|
|||
Como ves, los nombres de métodos ahora tienen el tag y luego el nombre de la función, ahora no incluyen información del path de la URL y la operación HTTP. |
|||
|
|||
### Preprocesa la Especificación OpenAPI para el Generador de Clientes |
|||
|
|||
El código generado aún tiene algo de **información duplicada**. |
|||
|
|||
Ya sabemos que este método está relacionado con los **items** porque esa palabra está en el `ItemsService` (tomado del tag), pero aún tenemos el nombre del tag prefijado en el nombre del método también. 😕 |
|||
|
|||
Probablemente aún querremos mantenerlo para OpenAPI en general, ya que eso asegurará que los operation IDs sean **únicos**. |
|||
|
|||
Pero para el cliente generado podríamos **modificar** los operation IDs de OpenAPI justo antes de generar los clientes, solo para hacer esos nombres de métodos más bonitos y **limpios**. |
|||
|
|||
Podríamos descargar el JSON de OpenAPI a un archivo `openapi.json` y luego podríamos **remover ese tag prefijado** con un script como este: |
|||
|
|||
{* ../../docs_src/generate_clients/tutorial004.py *} |
|||
|
|||
//// tab | Node.js |
|||
|
|||
```Javascript |
|||
{!> ../../docs_src/generate_clients/tutorial004.js!} |
|||
``` |
|||
|
|||
//// |
|||
|
|||
Con eso, los operation IDs serían renombrados de cosas como `items-get_items` a solo `get_items`, de esa manera el generador del cliente puede generar nombres de métodos más simples. |
|||
|
|||
### Generar un Cliente TypeScript con el OpenAPI Preprocesado |
|||
|
|||
Ahora como el resultado final está en un archivo `openapi.json`, modificarías el `package.json` para usar ese archivo local, por ejemplo: |
|||
|
|||
```JSON hl_lines="7" |
|||
{ |
|||
"name": "frontend-app", |
|||
"version": "1.0.0", |
|||
"description": "", |
|||
"main": "index.js", |
|||
"scripts": { |
|||
"generate-client": "openapi-ts --input ./openapi.json --output ./src/client --client axios" |
|||
}, |
|||
"author": "", |
|||
"license": "", |
|||
"devDependencies": { |
|||
"@hey-api/openapi-ts": "^0.27.38", |
|||
"typescript": "^4.6.2" |
|||
} |
|||
} |
|||
``` |
|||
|
|||
Después de generar el nuevo cliente, ahora tendrías nombres de métodos **limpios**, con todo el **autocompletado**, **errores en línea**, etc: |
|||
|
|||
<img src="/img/tutorial/generate-clients/image08.png"> |
|||
|
|||
## Beneficios |
|||
|
|||
Cuando usas los clientes generados automáticamente obtendrás **autocompletado** para: |
|||
|
|||
* Métodos. |
|||
* Payloads de peticiones en el cuerpo, parámetros de query, etc. |
|||
* Payloads de responses. |
|||
|
|||
También tendrás **errores en línea** para todo. |
|||
|
|||
Y cada vez que actualices el código del backend, y **regeneres** el frontend, tendrás las nuevas *path operations* disponibles como métodos, las antiguas eliminadas, y cualquier otro cambio se reflejará en el código generado. 🤓 |
|||
|
|||
Esto también significa que si algo cambió será **reflejado** automáticamente en el código del cliente. Y si haces **build** del cliente, te dará error si tienes algún **desajuste** en los datos utilizados. |
|||
|
|||
Así que, **detectarás muchos errores** muy temprano en el ciclo de desarrollo en lugar de tener que esperar a que los errores se muestren a tus usuarios finales en producción para luego intentar depurar dónde está el problema. ✨ |
@ -1,21 +1,36 @@ |
|||
# Guía de Usuario Avanzada |
|||
# Guía avanzada del usuario |
|||
|
|||
## Características Adicionales |
|||
## Funcionalidades adicionales |
|||
|
|||
El [Tutorial - Guía de Usuario](../tutorial/index.md){.internal-link target=_blank} principal debe ser suficiente para darte un paseo por todas las características principales de **FastAPI** |
|||
El [Tutorial - Guía del usuario](../tutorial/index.md){.internal-link target=_blank} principal debería ser suficiente para darte un recorrido por todas las funcionalidades principales de **FastAPI**. |
|||
|
|||
En las secciones siguientes verás otras opciones, configuraciones, y características adicionales. |
|||
En las siguientes secciones verás otras opciones, configuraciones y funcionalidades adicionales. |
|||
|
|||
/// tip | Consejo |
|||
|
|||
Las próximas secciones **no son necesariamente "avanzadas"**. |
|||
Las siguientes secciones **no son necesariamente "avanzadas"**. |
|||
|
|||
Y es posible que para tu caso, la solución se encuentre en una de estas. |
|||
Y es posible que para tu caso de uso, la solución esté en una de ellas. |
|||
|
|||
/// |
|||
|
|||
## Lee primero el Tutorial |
|||
|
|||
Puedes continuar usando la mayoría de las características de **FastAPI** con el conocimiento del [Tutorial - Guía de Usuario](../tutorial/index.md){.internal-link target=_blank} principal. |
|||
Aún podrías usar la mayoría de las funcionalidades en **FastAPI** con el conocimiento del [Tutorial - Guía del usuario](../tutorial/index.md){.internal-link target=_blank} principal. |
|||
|
|||
En las siguientes secciones se asume que lo has leído y conoces esas ideas principales. |
|||
Y las siguientes secciones asumen que ya lo leíste y que conoces esas ideas principales. |
|||
|
|||
## Cursos externos |
|||
|
|||
Aunque el [Tutorial - Guía del usuario](../tutorial/index.md){.internal-link target=_blank} y esta **Guía avanzada del usuario** están escritos como un tutorial guiado (como un libro) y deberían ser suficientes para que **aprendas FastAPI**, podrías querer complementarlo con cursos adicionales. |
|||
|
|||
O podría ser que simplemente prefieras tomar otros cursos porque se adaptan mejor a tu estilo de aprendizaje. |
|||
|
|||
Algunos proveedores de cursos ✨ [**sponsorean FastAPI**](../help-fastapi.md#sponsor-the-author){.internal-link target=_blank} ✨, esto asegura el desarrollo continuo y saludable de FastAPI y su **ecosistema**. |
|||
|
|||
Y muestra su verdadero compromiso con FastAPI y su **comunidad** (tú), ya que no solo quieren brindarte una **buena experiencia de aprendizaje** sino que también quieren asegurarse de que tengas un **buen y saludable framework**, FastAPI. 🙇 |
|||
|
|||
Podrías querer probar sus cursos: |
|||
|
|||
* <a href="https://training.talkpython.fm/fastapi-courses" class="external-link" target="_blank">Talk Python Training</a> |
|||
* <a href="https://testdriven.io/courses/tdd-fastapi/" class="external-link" target="_blank">Desarrollo guiado por pruebas</a> |
|||
|
@ -0,0 +1,96 @@ |
|||
# Middleware Avanzado |
|||
|
|||
En el tutorial principal leíste cómo agregar [Middleware Personalizado](../tutorial/middleware.md){.internal-link target=_blank} a tu aplicación. |
|||
|
|||
Y luego también leíste cómo manejar [CORS con el `CORSMiddleware`](../tutorial/cors.md){.internal-link target=_blank}. |
|||
|
|||
En esta sección veremos cómo usar otros middlewares. |
|||
|
|||
## Agregando middlewares ASGI |
|||
|
|||
Como **FastAPI** está basado en Starlette e implementa la especificación <abbr title="Asynchronous Server Gateway Interface">ASGI</abbr>, puedes usar cualquier middleware ASGI. |
|||
|
|||
Un middleware no tiene que estar hecho para FastAPI o Starlette para funcionar, siempre que siga la especificación ASGI. |
|||
|
|||
En general, los middlewares ASGI son clases que esperan recibir una aplicación ASGI como primer argumento. |
|||
|
|||
Entonces, en la documentación de middlewares ASGI de terceros probablemente te indicarán que hagas algo como: |
|||
|
|||
```Python |
|||
from unicorn import UnicornMiddleware |
|||
|
|||
app = SomeASGIApp() |
|||
|
|||
new_app = UnicornMiddleware(app, some_config="rainbow") |
|||
``` |
|||
|
|||
Pero FastAPI (en realidad Starlette) proporciona una forma más simple de hacerlo que asegura que los middlewares internos manejen errores del servidor y los controladores de excepciones personalizadas funcionen correctamente. |
|||
|
|||
Para eso, usas `app.add_middleware()` (como en el ejemplo para CORS). |
|||
|
|||
```Python |
|||
from fastapi import FastAPI |
|||
from unicorn import UnicornMiddleware |
|||
|
|||
app = FastAPI() |
|||
|
|||
app.add_middleware(UnicornMiddleware, some_config="rainbow") |
|||
``` |
|||
|
|||
`app.add_middleware()` recibe una clase de middleware como primer argumento y cualquier argumento adicional que se le quiera pasar al middleware. |
|||
|
|||
## Middlewares integrados |
|||
|
|||
**FastAPI** incluye varios middlewares para casos de uso común, veremos a continuación cómo usarlos. |
|||
|
|||
/// note | Detalles Técnicos |
|||
|
|||
Para los próximos ejemplos, también podrías usar `from starlette.middleware.something import SomethingMiddleware`. |
|||
|
|||
**FastAPI** proporciona varios middlewares en `fastapi.middleware` solo como una conveniencia para ti, el desarrollador. Pero la mayoría de los middlewares disponibles provienen directamente de Starlette. |
|||
|
|||
/// |
|||
|
|||
## `HTTPSRedirectMiddleware` |
|||
|
|||
Impone que todas las requests entrantes deben ser `https` o `wss`. |
|||
|
|||
Cualquier request entrante a `http` o `ws` será redirigida al esquema seguro. |
|||
|
|||
{* ../../docs_src/advanced_middleware/tutorial001.py hl[2,6] *} |
|||
|
|||
## `TrustedHostMiddleware` |
|||
|
|||
Impone que todas las requests entrantes tengan correctamente configurado el header `Host`, para proteger contra ataques de HTTP Host Header. |
|||
|
|||
{* ../../docs_src/advanced_middleware/tutorial002.py hl[2,6:8] *} |
|||
|
|||
Se soportan los siguientes argumentos: |
|||
|
|||
* `allowed_hosts` - Una list de nombres de dominio que deberían ser permitidos como nombres de host. Se soportan dominios comodín como `*.example.com` para hacer coincidir subdominios. Para permitir cualquier nombre de host, usa `allowed_hosts=["*"]` u omite el middleware. |
|||
|
|||
Si una request entrante no se valida correctamente, se enviará un response `400`. |
|||
|
|||
## `GZipMiddleware` |
|||
|
|||
Maneja responses GZip para cualquier request que incluya `"gzip"` en el header `Accept-Encoding`. |
|||
|
|||
El middleware manejará tanto responses estándar como en streaming. |
|||
|
|||
{* ../../docs_src/advanced_middleware/tutorial003.py hl[2,6] *} |
|||
|
|||
Se soportan los siguientes argumentos: |
|||
|
|||
* `minimum_size` - No comprimir con GZip responses que sean más pequeñas que este tamaño mínimo en bytes. Por defecto es `500`. |
|||
* `compresslevel` - Usado durante la compresión GZip. Es un entero que varía de 1 a 9. Por defecto es `9`. Un valor más bajo resulta en una compresión más rápida pero archivos más grandes, mientras que un valor más alto resulta en una compresión más lenta pero archivos más pequeños. |
|||
|
|||
## Otros middlewares |
|||
|
|||
Hay muchos otros middlewares ASGI. |
|||
|
|||
Por ejemplo: |
|||
|
|||
* <a href="https://github.com/encode/uvicorn/blob/master/uvicorn/middleware/proxy_headers.py" class="external-link" target="_blank">`ProxyHeadersMiddleware` de Uvicorn</a> |
|||
* <a href="https://github.com/florimondmanca/msgpack-asgi" class="external-link" target="_blank">MessagePack</a> |
|||
|
|||
Para ver otros middlewares disponibles, revisa <a href="https://www.starlette.io/middleware/" class="external-link" target="_blank">la documentación de Middleware de Starlette</a> y la <a href="https://github.com/florimondmanca/awesome-asgi" class="external-link" target="_blank">Lista ASGI Awesome</a>. |
@ -0,0 +1,186 @@ |
|||
# OpenAPI Callbacks |
|||
|
|||
Podrías crear una API con una *path operation* que podría desencadenar un request a una *API externa* creada por alguien más (probablemente el mismo desarrollador que estaría *usando* tu API). |
|||
|
|||
El proceso que ocurre cuando tu aplicación API llama a la *API externa* se llama un "callback". Porque el software que escribió el desarrollador externo envía un request a tu API y luego tu API *responde*, enviando un request a una *API externa* (que probablemente fue creada por el mismo desarrollador). |
|||
|
|||
En este caso, podrías querer documentar cómo esa API externa *debería* verse. Qué *path operation* debería tener, qué cuerpo debería esperar, qué response debería devolver, etc. |
|||
|
|||
## Una aplicación con callbacks |
|||
|
|||
Veamos todo esto con un ejemplo. |
|||
|
|||
Imagina que desarrollas una aplicación que permite crear facturas. |
|||
|
|||
Estas facturas tendrán un `id`, `title` (opcional), `customer`, y `total`. |
|||
|
|||
El usuario de tu API (un desarrollador externo) creará una factura en tu API con un request POST. |
|||
|
|||
Luego tu API (imaginemos): |
|||
|
|||
* Enviará la factura a algún cliente del desarrollador externo. |
|||
* Recogerá el dinero. |
|||
* Enviará una notificación de vuelta al usuario de la API (el desarrollador externo). |
|||
* Esto se hará enviando un request POST (desde *tu API*) a alguna *API externa* proporcionada por ese desarrollador externo (este es el "callback"). |
|||
|
|||
## La aplicación normal de **FastAPI** |
|||
|
|||
Primero veamos cómo sería la aplicación API normal antes de agregar el callback. |
|||
|
|||
Tendrá una *path operation* que recibirá un cuerpo `Invoice`, y un parámetro de query `callback_url` que contendrá la URL para el callback. |
|||
|
|||
Esta parte es bastante normal, probablemente ya estés familiarizado con la mayor parte del código: |
|||
|
|||
{* ../../docs_src/openapi_callbacks/tutorial001.py hl[9:13,36:53] *} |
|||
|
|||
/// tip | Consejo |
|||
|
|||
El parámetro de query `callback_url` utiliza un tipo <a href="https://docs.pydantic.dev/latest/api/networks/" class="external-link" target="_blank">Url</a> de Pydantic. |
|||
|
|||
/// |
|||
|
|||
Lo único nuevo es el `callbacks=invoices_callback_router.routes` como un argumento para el *decorador de path operation*. Veremos qué es eso a continuación. |
|||
|
|||
## Documentar el callback |
|||
|
|||
El código real del callback dependerá mucho de tu propia aplicación API. |
|||
|
|||
Y probablemente variará mucho de una aplicación a otra. |
|||
|
|||
Podría ser solo una o dos líneas de código, como: |
|||
|
|||
```Python |
|||
callback_url = "https://example.com/api/v1/invoices/events/" |
|||
httpx.post(callback_url, json={"description": "Invoice paid", "paid": True}) |
|||
``` |
|||
|
|||
Pero posiblemente la parte más importante del callback es asegurarse de que el usuario de tu API (el desarrollador externo) implemente la *API externa* correctamente, de acuerdo con los datos que *tu API* va a enviar en el request body del callback, etc. |
|||
|
|||
Entonces, lo que haremos a continuación es agregar el código para documentar cómo debería verse esa *API externa* para recibir el callback de *tu API*. |
|||
|
|||
Esa documentación aparecerá en la Swagger UI en `/docs` en tu API, y permitirá a los desarrolladores externos saber cómo construir la *API externa*. |
|||
|
|||
Este ejemplo no implementa el callback en sí (eso podría ser solo una línea de código), solo la parte de documentación. |
|||
|
|||
/// tip | Consejo |
|||
|
|||
El callback real es solo un request HTTP. |
|||
|
|||
Cuando implementes el callback tú mismo, podrías usar algo como <a href="https://www.python-httpx.org" class="external-link" target="_blank">HTTPX</a> o <a href="https://requests.readthedocs.io/" class="external-link" target="_blank">Requests</a>. |
|||
|
|||
/// |
|||
|
|||
## Escribir el código de documentación del callback |
|||
|
|||
Este código no se ejecutará en tu aplicación, solo lo necesitamos para *documentar* cómo debería verse esa *API externa*. |
|||
|
|||
Pero, ya sabes cómo crear fácilmente documentación automática para una API con **FastAPI**. |
|||
|
|||
Así que vamos a usar ese mismo conocimiento para documentar cómo debería verse la *API externa*... creando la(s) *path operation(s)* que la API externa debería implementar (las que tu API va a llamar). |
|||
|
|||
/// tip | Consejo |
|||
|
|||
Cuando escribas el código para documentar un callback, podría ser útil imaginar que eres ese *desarrollador externo*. Y que actualmente estás implementando la *API externa*, no *tu API*. |
|||
|
|||
Adoptar temporalmente este punto de vista (del *desarrollador externo*) puede ayudarte a sentir que es más obvio dónde poner los parámetros, el modelo de Pydantic para el body, para el response, etc. para esa *API externa*. |
|||
|
|||
/// |
|||
|
|||
### Crear un `APIRouter` de callback |
|||
|
|||
Primero crea un nuevo `APIRouter` que contendrá uno o más callbacks. |
|||
|
|||
{* ../../docs_src/openapi_callbacks/tutorial001.py hl[3,25] *} |
|||
|
|||
### Crear la *path operation* del callback |
|||
|
|||
Para crear la *path operation* del callback utiliza el mismo `APIRouter` que creaste anteriormente. |
|||
|
|||
Debería verse como una *path operation* normal de FastAPI: |
|||
|
|||
* Probablemente debería tener una declaración del body que debería recibir, por ejemplo `body: InvoiceEvent`. |
|||
* Y también podría tener una declaración del response que debería devolver, por ejemplo `response_model=InvoiceEventReceived`. |
|||
|
|||
{* ../../docs_src/openapi_callbacks/tutorial001.py hl[16:18,21:22,28:32] *} |
|||
|
|||
Hay 2 diferencias principales respecto a una *path operation* normal: |
|||
|
|||
* No necesita tener ningún código real, porque tu aplicación nunca llamará a este código. Solo se usa para documentar la *API externa*. Así que, la función podría simplemente tener `pass`. |
|||
* El *path* puede contener una <a href="https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.1.0.md#key-expression" class="external-link" target="_blank">expresión OpenAPI 3</a> (ver más abajo) donde puede usar variables con parámetros y partes del request original enviado a *tu API*. |
|||
|
|||
### La expresión del path del callback |
|||
|
|||
El *path* del callback puede tener una <a href="https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.1.0.md#key-expression" class="external-link" target="_blank">expresión OpenAPI 3</a> que puede contener partes del request original enviado a *tu API*. |
|||
|
|||
En este caso, es el `str`: |
|||
|
|||
```Python |
|||
"{$callback_url}/invoices/{$request.body.id}" |
|||
``` |
|||
|
|||
Entonces, si el usuario de tu API (el desarrollador externo) envía un request a *tu API* a: |
|||
|
|||
``` |
|||
https://yourapi.com/invoices/?callback_url=https://www.external.org/events |
|||
``` |
|||
|
|||
con un JSON body de: |
|||
|
|||
```JSON |
|||
{ |
|||
"id": "2expen51ve", |
|||
"customer": "Mr. Richie Rich", |
|||
"total": "9999" |
|||
} |
|||
``` |
|||
|
|||
luego *tu API* procesará la factura, y en algún momento después, enviará un request de callback al `callback_url` (la *API externa*): |
|||
|
|||
``` |
|||
https://www.external.org/events/invoices/2expen51ve |
|||
``` |
|||
|
|||
con un JSON body que contiene algo como: |
|||
|
|||
```JSON |
|||
{ |
|||
"description": "Payment celebration", |
|||
"paid": true |
|||
} |
|||
``` |
|||
|
|||
y esperaría un response de esa *API externa* con un JSON body como: |
|||
|
|||
```JSON |
|||
{ |
|||
"ok": true |
|||
} |
|||
``` |
|||
|
|||
/// tip | Consejo |
|||
|
|||
Observa cómo la URL del callback utilizada contiene la URL recibida como parámetro de query en `callback_url` (`https://www.external.org/events`) y también el `id` de la factura desde dentro del JSON body (`2expen51ve`). |
|||
|
|||
/// |
|||
|
|||
### Agregar el router de callback |
|||
|
|||
En este punto tienes las *path operation(s)* del callback necesarias (las que el *desarrollador externo* debería implementar en la *API externa*) en el router de callback que creaste antes. |
|||
|
|||
Ahora usa el parámetro `callbacks` en el *decorador de path operation de tu API* para pasar el atributo `.routes` (que en realidad es solo un `list` de rutas/*path operations*) de ese router de callback: |
|||
|
|||
{* ../../docs_src/openapi_callbacks/tutorial001.py hl[35] *} |
|||
|
|||
/// tip | Consejo |
|||
|
|||
Observa que no estás pasando el router en sí (`invoices_callback_router`) a `callback=`, sino el atributo `.routes`, como en `invoices_callback_router.routes`. |
|||
|
|||
/// |
|||
|
|||
### Revisa la documentación |
|||
|
|||
Ahora puedes iniciar tu aplicación e ir a <a href="http://127.0.0.1:8000/docs" class="external-link" target="_blank">http://127.0.0.1:8000/docs</a>. |
|||
|
|||
Verás tu documentación incluyendo una sección de "Callbacks" para tu *path operation* que muestra cómo debería verse la *API externa*: |
|||
|
|||
<img src="/img/tutorial/openapi-callbacks/image01.png"> |
@ -0,0 +1,55 @@ |
|||
# Webhooks de OpenAPI |
|||
|
|||
Hay casos donde quieres decirle a los **usuarios** de tu API que tu aplicación podría llamar a *su* aplicación (enviando una request) con algunos datos, normalmente para **notificar** de algún tipo de **evento**. |
|||
|
|||
Esto significa que en lugar del proceso normal de tus usuarios enviando requests a tu API, es **tu API** (o tu aplicación) la que podría **enviar requests a su sistema** (a su API, su aplicación). |
|||
|
|||
Esto normalmente se llama un **webhook**. |
|||
|
|||
## Pasos de los webhooks |
|||
|
|||
El proceso normalmente es que **tú defines** en tu código cuál es el mensaje que enviarás, el **body de la request**. |
|||
|
|||
También defines de alguna manera en qué **momentos** tu aplicación enviará esas requests o eventos. |
|||
|
|||
Y **tus usuarios** definen de alguna manera (por ejemplo en un panel web en algún lugar) el **URL** donde tu aplicación debería enviar esas requests. |
|||
|
|||
Toda la **lógica** sobre cómo registrar los URLs para webhooks y el código para realmente enviar esas requests depende de ti. Lo escribes como quieras en **tu propio código**. |
|||
|
|||
## Documentando webhooks con **FastAPI** y OpenAPI |
|||
|
|||
Con **FastAPI**, usando OpenAPI, puedes definir los nombres de estos webhooks, los tipos de operaciones HTTP que tu aplicación puede enviar (por ejemplo, `POST`, `PUT`, etc.) y los **bodies** de las requests que tu aplicación enviaría. |
|||
|
|||
Esto puede hacer mucho más fácil para tus usuarios **implementar sus APIs** para recibir tus requests de **webhook**, incluso podrían ser capaces de autogenerar algo de su propio código de API. |
|||
|
|||
/// info | Información |
|||
|
|||
Los webhooks están disponibles en OpenAPI 3.1.0 y superiores, soportados por FastAPI `0.99.0` y superiores. |
|||
|
|||
/// |
|||
|
|||
## Una aplicación con webhooks |
|||
|
|||
Cuando creas una aplicación de **FastAPI**, hay un atributo `webhooks` que puedes usar para definir *webhooks*, de la misma manera que definirías *path operations*, por ejemplo con `@app.webhooks.post()`. |
|||
|
|||
{* ../../docs_src/openapi_webhooks/tutorial001.py hl[9:13,36:53] *} |
|||
|
|||
Los webhooks que defines terminarán en el esquema de **OpenAPI** y en la interfaz automática de **documentación**. |
|||
|
|||
/// info | Información |
|||
|
|||
El objeto `app.webhooks` es en realidad solo un `APIRouter`, el mismo tipo que usarías al estructurar tu aplicación con múltiples archivos. |
|||
|
|||
/// |
|||
|
|||
Nota que con los webhooks en realidad no estás declarando un *path* (como `/items/`), el texto que pasas allí es solo un **identificador** del webhook (el nombre del evento), por ejemplo en `@app.webhooks.post("new-subscription")`, el nombre del webhook es `new-subscription`. |
|||
|
|||
Esto es porque se espera que **tus usuarios** definan el actual **URL path** donde quieren recibir la request del webhook de alguna otra manera (por ejemplo, un panel web). |
|||
|
|||
### Revisa la documentación |
|||
|
|||
Ahora puedes iniciar tu app e ir a <a href="http://127.0.0.1:8000/docs" class="external-link" target="_blank">http://127.0.0.1:8000/docs</a>. |
|||
|
|||
Verás que tu documentación tiene las *path operations* normales y ahora también algunos **webhooks**: |
|||
|
|||
<img src="/img/tutorial/openapi-webhooks/image01.png"> |
@ -1,53 +1,204 @@ |
|||
# Configuración avanzada de las operaciones de path |
|||
# Configuración Avanzada de Path Operation |
|||
|
|||
## OpenAPI operationId |
|||
## operationId de OpenAPI |
|||
|
|||
/// warning | Advertencia |
|||
|
|||
Si no eres una persona "experta" en OpenAPI, probablemente no necesitas leer esto. |
|||
Si no eres un "experto" en OpenAPI, probablemente no necesites esto. |
|||
|
|||
/// |
|||
|
|||
Puedes asignar el `operationId` de OpenAPI para ser usado en tu *operación de path* con el parámetro `operation_id`. |
|||
Puedes establecer el `operationId` de OpenAPI para ser usado en tu *path operation* con el parámetro `operation_id`. |
|||
|
|||
En este caso tendrías que asegurarte de que sea único para cada operación. |
|||
Tienes que asegurarte de que sea único para cada operación. |
|||
|
|||
{* ../../docs_src/path_operation_advanced_configuration/tutorial001.py hl[6] *} |
|||
|
|||
### Usando el nombre de la *función de la operación de path* en el operationId |
|||
### Usar el nombre de la *función de path operation* como el operationId |
|||
|
|||
Si quieres usar tus nombres de funciones de API como `operationId`s, puedes iterar sobre todos ellos y sobrescribir `operation_id` de cada *operación de path* usando su `APIRoute.name`. |
|||
Si quieres usar los nombres de las funciones de tus APIs como `operationId`s, puedes iterar sobre todas ellas y sobrescribir el `operation_id` de cada *path operation* usando su `APIRoute.name`. |
|||
|
|||
Deberías hacerlo después de adicionar todas tus *operaciones de path*. |
|||
Deberías hacerlo después de agregar todas tus *path operations*. |
|||
|
|||
{* ../../docs_src/path_operation_advanced_configuration/tutorial002.py hl[2,12,13,14,15,16,17,18,19,20,21,24] *} |
|||
{* ../../docs_src/path_operation_advanced_configuration/tutorial002.py hl[2, 12:21, 24] *} |
|||
|
|||
/// tip | Consejo |
|||
|
|||
Si llamas manualmente a `app.openapi()`, debes actualizar el `operationId`s antes de hacerlo. |
|||
Si llamas manualmente a `app.openapi()`, deberías actualizar los `operationId`s antes de eso. |
|||
|
|||
/// |
|||
|
|||
/// warning | Advertencia |
|||
|
|||
Si haces esto, debes asegurarte de que cada una de tus *funciones de las operaciones de path* tenga un nombre único. |
|||
Si haces esto, tienes que asegurarte de que cada una de tus *funciones de path operation* tenga un nombre único. |
|||
|
|||
Incluso si están en diferentes módulos (archivos Python). |
|||
Incluso si están en diferentes módulos (archivos de Python). |
|||
|
|||
/// |
|||
|
|||
## Excluir de OpenAPI |
|||
|
|||
Para excluir una *operación de path* del esquema OpenAPI generado (y por tanto del la documentación generada automáticamente), usa el parámetro `include_in_schema` y asigna el valor como `False`; |
|||
Para excluir una *path operation* del esquema OpenAPI generado (y por lo tanto, de los sistemas de documentación automática), utiliza el parámetro `include_in_schema` y configúralo en `False`: |
|||
|
|||
{* ../../docs_src/path_operation_advanced_configuration/tutorial003.py hl[6] *} |
|||
|
|||
## Descripción avanzada desde el docstring |
|||
|
|||
Puedes limitar las líneas usadas desde el docstring de una *operación de path* para OpenAPI. |
|||
Puedes limitar las líneas usadas del docstring de una *función de path operation* para OpenAPI. |
|||
|
|||
Agregar un `\f` (un carácter de "form feed" escapado) hace que **FastAPI** trunque el output utilizada para OpenAPI en ese punto. |
|||
Añadir un `\f` (un carácter de separación de página escapado) hace que **FastAPI** trunque la salida usada para OpenAPI en este punto. |
|||
|
|||
No será mostrado en la documentación, pero otras herramientas (como Sphinx) serán capaces de usar el resto. |
|||
No aparecerá en la documentación, pero otras herramientas (como Sphinx) podrán usar el resto. |
|||
|
|||
{* ../../docs_src/path_operation_advanced_configuration/tutorial004.py hl[19,20,21,22,23,24,25,26,27,28,29] *} |
|||
{* ../../docs_src/path_operation_advanced_configuration/tutorial004.py hl[19:29] *} |
|||
|
|||
## Responses Adicionales |
|||
|
|||
Probablemente has visto cómo declarar el `response_model` y el `status_code` para una *path operation*. |
|||
|
|||
Eso define los metadatos sobre el response principal de una *path operation*. |
|||
|
|||
También puedes declarar responses adicionales con sus modelos, códigos de estado, etc. |
|||
|
|||
Hay un capítulo entero en la documentación sobre ello, puedes leerlo en [Responses Adicionales en OpenAPI](additional-responses.md){.internal-link target=_blank}. |
|||
|
|||
## OpenAPI Extra |
|||
|
|||
Cuando declaras una *path operation* en tu aplicación, **FastAPI** genera automáticamente los metadatos relevantes sobre esa *path operation* para incluirlos en el esquema de OpenAPI. |
|||
|
|||
/// note | Nota |
|||
|
|||
En la especificación de OpenAPI se llama el <a href="https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.3.md#operation-object" class="external-link" target="_blank">Objeto de Operación</a>. |
|||
|
|||
/// |
|||
|
|||
Tiene toda la información sobre la *path operation* y se usa para generar la documentación automática. |
|||
|
|||
Incluye los `tags`, `parameters`, `requestBody`, `responses`, etc. |
|||
|
|||
Este esquema de OpenAPI específico de *path operation* normalmente se genera automáticamente por **FastAPI**, pero también puedes extenderlo. |
|||
|
|||
/// tip | Consejo |
|||
|
|||
Este es un punto de extensión de bajo nivel. |
|||
|
|||
Si solo necesitas declarar responses adicionales, una forma más conveniente de hacerlo es con [Responses Adicionales en OpenAPI](additional-responses.md){.internal-link target=_blank}. |
|||
|
|||
/// |
|||
|
|||
Puedes extender el esquema de OpenAPI para una *path operation* usando el parámetro `openapi_extra`. |
|||
|
|||
### Extensiones de OpenAPI |
|||
|
|||
Este `openapi_extra` puede ser útil, por ejemplo, para declarar [Extensiones de OpenAPI](https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.3.md#specificationExtensions): |
|||
|
|||
{* ../../docs_src/path_operation_advanced_configuration/tutorial005.py hl[6] *} |
|||
|
|||
Si abres la documentación automática de la API, tu extensión aparecerá en la parte inferior de la *path operation* específica. |
|||
|
|||
<img src="/img/tutorial/path-operation-advanced-configuration/image01.png"> |
|||
|
|||
Y si ves el OpenAPI resultante (en `/openapi.json` en tu API), verás tu extensión como parte de la *path operation* específica también: |
|||
|
|||
```JSON hl_lines="22" |
|||
{ |
|||
"openapi": "3.1.0", |
|||
"info": { |
|||
"title": "FastAPI", |
|||
"version": "0.1.0" |
|||
}, |
|||
"paths": { |
|||
"/items/": { |
|||
"get": { |
|||
"summary": "Read Items", |
|||
"operationId": "read_items_items__get", |
|||
"responses": { |
|||
"200": { |
|||
"description": "Successful Response", |
|||
"content": { |
|||
"application/json": { |
|||
"schema": {} |
|||
} |
|||
} |
|||
} |
|||
}, |
|||
"x-aperture-labs-portal": "blue" |
|||
} |
|||
} |
|||
} |
|||
} |
|||
``` |
|||
|
|||
### Esquema de *path operation* personalizada de OpenAPI |
|||
|
|||
El diccionario en `openapi_extra` se combinará profundamente con el esquema de OpenAPI generado automáticamente para la *path operation*. |
|||
|
|||
Por lo tanto, podrías añadir datos adicionales al esquema generado automáticamente. |
|||
|
|||
Por ejemplo, podrías decidir leer y validar el request con tu propio código, sin usar las funcionalidades automáticas de FastAPI con Pydantic, pero aún podrías querer definir el request en el esquema de OpenAPI. |
|||
|
|||
Podrías hacer eso con `openapi_extra`: |
|||
|
|||
{* ../../docs_src/path_operation_advanced_configuration/tutorial006.py hl[19:36, 39:40] *} |
|||
|
|||
En este ejemplo, no declaramos ningún modelo Pydantic. De hecho, el cuerpo del request ni siquiera se <abbr title="converted from some plain format, like bytes, into Python objects">parse</abbr> como JSON, se lee directamente como `bytes`, y la función `magic_data_reader()` sería la encargada de parsearlo de alguna manera. |
|||
|
|||
Sin embargo, podemos declarar el esquema esperado para el cuerpo del request. |
|||
|
|||
### Tipo de contenido personalizado de OpenAPI |
|||
|
|||
Usando este mismo truco, podrías usar un modelo Pydantic para definir el esquema JSON que luego se incluye en la sección personalizada del esquema OpenAPI para la *path operation*. |
|||
|
|||
Y podrías hacer esto incluso si el tipo de datos en el request no es JSON. |
|||
|
|||
Por ejemplo, en esta aplicación no usamos la funcionalidad integrada de FastAPI para extraer el esquema JSON de los modelos Pydantic ni la validación automática para JSON. De hecho, estamos declarando el tipo de contenido del request como YAML, no JSON: |
|||
|
|||
//// tab | Pydantic v2 |
|||
|
|||
{* ../../docs_src/path_operation_advanced_configuration/tutorial007.py hl[17:22, 24] *} |
|||
|
|||
//// |
|||
|
|||
//// tab | Pydantic v1 |
|||
|
|||
{* ../../docs_src/path_operation_advanced_configuration/tutorial007_pv1.py hl[17:22, 24] *} |
|||
|
|||
//// |
|||
|
|||
/// info | Información |
|||
|
|||
En la versión 1 de Pydantic el método para obtener el esquema JSON para un modelo se llamaba `Item.schema()`, en la versión 2 de Pydantic, el método se llama `Item.model_json_schema()`. |
|||
|
|||
/// |
|||
|
|||
Sin embargo, aunque no estamos usando la funcionalidad integrada por defecto, aún estamos usando un modelo Pydantic para generar manualmente el esquema JSON para los datos que queremos recibir en YAML. |
|||
|
|||
Luego usamos el request directamente, y extraemos el cuerpo como `bytes`. Esto significa que FastAPI ni siquiera intentará parsear la carga útil del request como JSON. |
|||
|
|||
Y luego en nuestro código, parseamos ese contenido YAML directamente, y nuevamente estamos usando el mismo modelo Pydantic para validar el contenido YAML: |
|||
|
|||
//// tab | Pydantic v2 |
|||
|
|||
{* ../../docs_src/path_operation_advanced_configuration/tutorial007.py hl[26:33] *} |
|||
|
|||
//// |
|||
|
|||
//// tab | Pydantic v1 |
|||
|
|||
{* ../../docs_src/path_operation_advanced_configuration/tutorial007_pv1.py hl[26:33] *} |
|||
|
|||
//// |
|||
|
|||
/// info | Información |
|||
|
|||
En la versión 1 de Pydantic el método para parsear y validar un objeto era `Item.parse_obj()`, en la versión 2 de Pydantic, el método se llama `Item.model_validate()`. |
|||
|
|||
/// |
|||
|
|||
/// tip | Consejo |
|||
|
|||
Aquí reutilizamos el mismo modelo Pydantic. |
|||
|
|||
Pero de la misma manera, podríamos haberlo validado de alguna otra forma. |
|||
|
|||
/// |
|||
|
@ -1,31 +1,31 @@ |
|||
# Response - Cambiar el Status Code |
|||
# Response - Cambiar Código de Estado |
|||
|
|||
Probablemente ya has leído con anterioridad que puedes establecer un [Response Status Code](../tutorial/response-status-code.md){.internal-link target=_blank} por defecto. |
|||
Probablemente leíste antes que puedes establecer un [Código de Estado de Response](../tutorial/response-status-code.md){.internal-link target=_blank} por defecto. |
|||
|
|||
Pero en algunos casos necesitas retornar un status code diferente al predeterminado. |
|||
Pero en algunos casos necesitas devolver un código de estado diferente al predeterminado. |
|||
|
|||
## Casos de uso |
|||
## Caso de uso |
|||
|
|||
Por ejemplo, imagina que quieres retornar un HTTP status code de "OK" `200` por defecto. |
|||
Por ejemplo, imagina que quieres devolver un código de estado HTTP de "OK" `200` por defecto. |
|||
|
|||
Pero si los datos no existen, quieres crearlos y retornar un HTTP status code de "CREATED" `201`. |
|||
Pero si los datos no existieran, quieres crearlos y devolver un código de estado HTTP de "CREATED" `201`. |
|||
|
|||
Pero aún quieres poder filtrar y convertir los datos que retornas con un `response_model`. |
|||
Pero todavía quieres poder filtrar y convertir los datos que devuelves con un `response_model`. |
|||
|
|||
Para esos casos, puedes usar un parámetro `Response`. |
|||
|
|||
## Usar un parámetro `Response` |
|||
## Usa un parámetro `Response` |
|||
|
|||
Puedes declarar un parámetro de tipo `Response` en tu *función de la operación de path* (como puedes hacer para cookies y headers). |
|||
Puedes declarar un parámetro de tipo `Response` en tu *función de path operation* (como puedes hacer para cookies y headers). |
|||
|
|||
Y luego puedes establecer el `status_code` en ese objeto de respuesta *temporal*. |
|||
Y luego puedes establecer el `status_code` en ese objeto de response *temporal*. |
|||
|
|||
{* ../../docs_src/response_change_status_code/tutorial001.py hl[1,9,12] *} |
|||
|
|||
Y luego puedes retornar cualquier objeto que necesites, como normalmente lo harías (un `dict`, un modelo de base de datos, etc). |
|||
Y luego puedes devolver cualquier objeto que necesites, como lo harías normalmente (un `dict`, un modelo de base de datos, etc.). |
|||
|
|||
Y si declaraste un `response_model`, aún se usará para filtrar y convertir el objeto que retornaste. |
|||
Y si declaraste un `response_model`, todavía se utilizará para filtrar y convertir el objeto que devolviste. |
|||
|
|||
**FastAPI** usará esa respuesta *temporal* para extraer el código de estado (también cookies y headers), y los pondrá en la respuesta final que contiene el valor que retornaste, filtrado por cualquier `response_model`. |
|||
**FastAPI** usará ese response *temporal* para extraer el código de estado (también cookies y headers), y los pondrá en el response final que contiene el valor que devolviste, filtrado por cualquier `response_model`. |
|||
|
|||
También puedes declarar la dependencia del parámetro `Response`, y establecer el código de estado en ellos. Pero ten en cuenta que el último en establecerse será el que gane. |
|||
También puedes declarar el parámetro `Response` en dependencias y establecer el código de estado en ellas. Pero ten en cuenta que el último establecido prevalecerá. |
|||
|
@ -0,0 +1,51 @@ |
|||
# Cookies de Response |
|||
|
|||
## Usar un parámetro `Response` |
|||
|
|||
Puedes declarar un parámetro de tipo `Response` en tu *path operation function*. |
|||
|
|||
Y luego puedes establecer cookies en ese objeto de response *temporal*. |
|||
|
|||
{* ../../docs_src/response_cookies/tutorial002.py hl[1, 8:9] *} |
|||
|
|||
Y entonces puedes devolver cualquier objeto que necesites, como normalmente lo harías (un `dict`, un modelo de base de datos, etc). |
|||
|
|||
Y si declaraste un `response_model`, todavía se utilizará para filtrar y convertir el objeto que devolviste. |
|||
|
|||
**FastAPI** utilizará ese response *temporal* para extraer las cookies (también los headers y el código de estado), y las pondrá en el response final que contiene el valor que devolviste, filtrado por cualquier `response_model`. |
|||
|
|||
También puedes declarar el parámetro `Response` en las dependencias, y establecer cookies (y headers) en ellas. |
|||
|
|||
## Devolver una `Response` directamente |
|||
|
|||
También puedes crear cookies al devolver una `Response` directamente en tu código. |
|||
|
|||
Para hacer eso, puedes crear un response como se describe en [Devolver un Response Directamente](response-directly.md){.internal-link target=_blank}. |
|||
|
|||
Luego establece Cookies en ella, y luego devuélvela: |
|||
|
|||
{* ../../docs_src/response_cookies/tutorial001.py hl[10:12] *} |
|||
|
|||
/// tip | Consejo |
|||
|
|||
Ten en cuenta que si devuelves un response directamente en lugar de usar el parámetro `Response`, FastAPI lo devolverá directamente. |
|||
|
|||
Así que tendrás que asegurarte de que tus datos son del tipo correcto. Por ejemplo, que sea compatible con JSON, si estás devolviendo un `JSONResponse`. |
|||
|
|||
Y también que no estés enviando ningún dato que debería haber sido filtrado por un `response_model`. |
|||
|
|||
/// |
|||
|
|||
### Más información |
|||
|
|||
/// note | Detalles Técnicos |
|||
|
|||
También podrías usar `from starlette.responses import Response` o `from starlette.responses import JSONResponse`. |
|||
|
|||
**FastAPI** proporciona los mismos `starlette.responses` como `fastapi.responses` solo como una conveniencia para ti, el desarrollador. Pero la mayoría de los responses disponibles vienen directamente de Starlette. |
|||
|
|||
Y como el `Response` se puede usar frecuentemente para establecer headers y cookies, **FastAPI** también lo proporciona en `fastapi.Response`. |
|||
|
|||
/// |
|||
|
|||
Para ver todos los parámetros y opciones disponibles, revisa la <a href="https://www.starlette.io/responses/#set-cookie" class="external-link" target="_blank">documentación en Starlette</a>. |
@ -1,43 +1,41 @@ |
|||
# Headers de Respuesta |
|||
# Response Headers |
|||
|
|||
## Usar un parámetro `Response` |
|||
## Usa un parámetro `Response` |
|||
|
|||
Puedes declarar un parámetro de tipo `Response` en tu *función de operación de path* (de manera similar como se hace con las cookies). |
|||
Puedes declarar un parámetro de tipo `Response` en tu *función de path operation* (como puedes hacer para cookies). |
|||
|
|||
Y entonces, podrás configurar las cookies en ese objeto de response *temporal*. |
|||
Y luego puedes establecer headers en ese objeto de response *temporal*. |
|||
|
|||
{* ../../docs_src/response_headers/tutorial002.py hl[1,7:8] *} |
|||
{* ../../docs_src/response_headers/tutorial002.py hl[1, 7:8] *} |
|||
|
|||
Posteriormente, puedes devolver cualquier objeto que necesites, como normalmente harías (un `dict`, un modelo de base de datos, etc). |
|||
Y luego puedes devolver cualquier objeto que necesites, como harías normalmente (un `dict`, un modelo de base de datos, etc). |
|||
|
|||
Si declaraste un `response_model`, este se continuará usando para filtrar y convertir el objeto que devolviste. |
|||
Y si declaraste un `response_model`, aún se usará para filtrar y convertir el objeto que devolviste. |
|||
|
|||
**FastAPI** usará ese response *temporal* para extraer los headers (al igual que las cookies y el status code), además las pondrá en el response final que contendrá el valor retornado y filtrado por algún `response_model`. |
|||
**FastAPI** usará ese response *temporal* para extraer los headers (también cookies y el código de estado), y los pondrá en el response final que contiene el valor que devolviste, filtrado por cualquier `response_model`. |
|||
|
|||
También puedes declarar el parámetro `Response` en dependencias, así como configurar los headers (y las cookies) en ellas. |
|||
También puedes declarar el parámetro `Response` en dependencias y establecer headers (y cookies) en ellas. |
|||
|
|||
## Retorna una `Response` directamente |
|||
|
|||
## Retornar una `Response` directamente |
|||
También puedes agregar headers cuando devuelves un `Response` directamente. |
|||
|
|||
Adicionalmente, puedes añadir headers cuando se retorne una `Response` directamente. |
|||
|
|||
Crea un response tal como se describe en [Retornar una respuesta directamente](response-directly.md){.internal-link target=_blank} y pasa los headers como un parámetro adicional: |
|||
Crea un response como se describe en [Retorna un Response Directamente](response-directly.md){.internal-link target=_blank} y pasa los headers como un parámetro adicional: |
|||
|
|||
{* ../../docs_src/response_headers/tutorial001.py hl[10:12] *} |
|||
|
|||
/// note | Detalles Técnicos |
|||
|
|||
También podrías utilizar `from starlette.responses import Response` o `from starlette.responses import JSONResponse`. |
|||
|
|||
**FastAPI** proporciona las mismas `starlette.responses` en `fastapi.responses` sólo que de una manera más conveniente para ti, el desarrollador. En otras palabras, muchas de las responses disponibles provienen directamente de Starlette. |
|||
También podrías usar `from starlette.responses import Response` o `from starlette.responses import JSONResponse`. |
|||
|
|||
**FastAPI** proporciona las mismas `starlette.responses` como `fastapi.responses` solo por conveniencia para ti, el desarrollador. Pero la mayoría de los responses disponibles provienen directamente de Starlette. |
|||
|
|||
Y como la `Response` puede ser usada frecuentemente para configurar headers y cookies, **FastAPI** también la provee en `fastapi.Response`. |
|||
Y como el `Response` se puede usar frecuentemente para establecer headers y cookies, **FastAPI** también lo proporciona en `fastapi.Response`. |
|||
|
|||
/// |
|||
|
|||
## Headers Personalizados |
|||
|
|||
Ten en cuenta que se pueden añadir headers propietarios personalizados <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers" class="external-link" target="_blank">usando el prefijo 'X-'</a>. |
|||
Ten en cuenta que los headers propietarios personalizados se pueden agregar <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers" class="external-link" target="_blank">usando el prefijo 'X-'</a>. |
|||
|
|||
Si tienes headers personalizados y deseas que un cliente pueda verlos en el navegador, es necesario que los añadas a tus configuraciones de CORS (puedes leer más en [CORS (Cross-Origin Resource Sharing)](../tutorial/cors.md){.internal-link target=_blank}), usando el parámetro `expose_headers` documentado en <a href="https://www.starlette.io/middleware/#corsmiddleware" class="external-link" target="_blank">Starlette's CORS docs</a>. |
|||
Pero si tienes headers personalizados que quieres que un cliente en un navegador pueda ver, necesitas agregarlos a tus configuraciones de CORS (leer más en [CORS (Cross-Origin Resource Sharing)](../tutorial/cors.md){.internal-link target=_blank}), usando el parámetro `expose_headers` documentado en <a href="https://www.starlette.io/middleware/#corsmiddleware" class="external-link" target="_blank">la documentación CORS de Starlette</a>. |
|||
|
@ -0,0 +1,107 @@ |
|||
# HTTP Basic Auth |
|||
|
|||
Para los casos más simples, puedes usar HTTP Basic Auth. |
|||
|
|||
En HTTP Basic Auth, la aplicación espera un header que contiene un nombre de usuario y una contraseña. |
|||
|
|||
Si no lo recibe, devuelve un error HTTP 401 "Unauthorized". |
|||
|
|||
Y devuelve un header `WWW-Authenticate` con un valor de `Basic`, y un parámetro `realm` opcional. |
|||
|
|||
Eso le dice al navegador que muestre el prompt integrado para un nombre de usuario y contraseña. |
|||
|
|||
Luego, cuando escribes ese nombre de usuario y contraseña, el navegador los envía automáticamente en el header. |
|||
|
|||
## Simple HTTP Basic Auth |
|||
|
|||
* Importa `HTTPBasic` y `HTTPBasicCredentials`. |
|||
* Crea un "esquema de `security`" usando `HTTPBasic`. |
|||
* Usa ese `security` con una dependencia en tu *path operation*. |
|||
* Devuelve un objeto de tipo `HTTPBasicCredentials`: |
|||
* Contiene el `username` y `password` enviados. |
|||
|
|||
{* ../../docs_src/security/tutorial006_an_py39.py hl[4,8,12] *} |
|||
|
|||
Cuando intentas abrir la URL por primera vez (o haces clic en el botón "Execute" en la documentación) el navegador te pedirá tu nombre de usuario y contraseña: |
|||
|
|||
<img src="/img/tutorial/security/image12.png"> |
|||
|
|||
## Revisa el nombre de usuario |
|||
|
|||
Aquí hay un ejemplo más completo. |
|||
|
|||
Usa una dependencia para comprobar si el nombre de usuario y la contraseña son correctos. |
|||
|
|||
Para esto, usa el módulo estándar de Python <a href="https://docs.python.org/3/library/secrets.html" class="external-link" target="_blank">`secrets`</a> para verificar el nombre de usuario y la contraseña. |
|||
|
|||
`secrets.compare_digest()` necesita tomar `bytes` o un `str` que solo contenga caracteres ASCII (los carácteres en inglés), esto significa que no funcionaría con caracteres como `á`, como en `Sebastián`. |
|||
|
|||
Para manejar eso, primero convertimos el `username` y `password` a `bytes` codificándolos con UTF-8. |
|||
|
|||
Luego podemos usar `secrets.compare_digest()` para asegurar que `credentials.username` es `"stanleyjobson"`, y que `credentials.password` es `"swordfish"`. |
|||
|
|||
{* ../../docs_src/security/tutorial007_an_py39.py hl[1,12:24] *} |
|||
|
|||
Esto sería similar a: |
|||
|
|||
```Python |
|||
if not (credentials.username == "stanleyjobson") or not (credentials.password == "swordfish"): |
|||
# Return some error |
|||
... |
|||
``` |
|||
|
|||
Pero al usar `secrets.compare_digest()` será seguro contra un tipo de ataques llamados "timing attacks". |
|||
|
|||
### Timing Attacks |
|||
|
|||
¿Pero qué es un "timing attack"? |
|||
|
|||
Imaginemos que algunos atacantes están tratando de adivinar el nombre de usuario y la contraseña. |
|||
|
|||
Y envían un request con un nombre de usuario `johndoe` y una contraseña `love123`. |
|||
|
|||
Entonces el código de Python en tu aplicación equivaldría a algo como: |
|||
|
|||
```Python |
|||
if "johndoe" == "stanleyjobson" and "love123" == "swordfish": |
|||
... |
|||
``` |
|||
|
|||
Pero justo en el momento en que Python compara la primera `j` en `johndoe` con la primera `s` en `stanleyjobson`, devolverá `False`, porque ya sabe que esas dos strings no son iguales, pensando que "no hay necesidad de gastar más computación comparando el resto de las letras". Y tu aplicación dirá "Nombre de usuario o contraseña incorrectos". |
|||
|
|||
Pero luego los atacantes prueban con el nombre de usuario `stanleyjobsox` y contraseña `love123`. |
|||
|
|||
Y el código de tu aplicación hace algo así como: |
|||
|
|||
```Python |
|||
if "stanleyjobsox" == "stanleyjobson" and "love123" == "swordfish": |
|||
... |
|||
``` |
|||
|
|||
Python tendrá que comparar todo `stanleyjobso` en ambos `stanleyjobsox` y `stanleyjobson` antes de darse cuenta de que ambas strings no son las mismas. Así que tomará algunos microsegundos extra para responder "Nombre de usuario o contraseña incorrectos". |
|||
|
|||
#### El tiempo de respuesta ayuda a los atacantes |
|||
|
|||
En ese punto, al notar que el servidor tardó algunos microsegundos más en enviar el response "Nombre de usuario o contraseña incorrectos", los atacantes sabrán que acertaron en _algo_, algunas de las letras iniciales eran correctas. |
|||
|
|||
Y luego pueden intentar de nuevo sabiendo que probablemente es algo más similar a `stanleyjobsox` que a `johndoe`. |
|||
|
|||
#### Un ataque "profesional" |
|||
|
|||
Por supuesto, los atacantes no intentarían todo esto a mano, escribirían un programa para hacerlo, posiblemente con miles o millones de pruebas por segundo. Y obtendrían solo una letra correcta adicional a la vez. |
|||
|
|||
Pero haciendo eso, en algunos minutos u horas, los atacantes habrían adivinado el nombre de usuario y la contraseña correctos, con la "ayuda" de nuestra aplicación, solo usando el tiempo tomado para responder. |
|||
|
|||
#### Arréglalo con `secrets.compare_digest()` |
|||
|
|||
Pero en nuestro código estamos usando realmente `secrets.compare_digest()`. |
|||
|
|||
En resumen, tomará el mismo tiempo comparar `stanleyjobsox` con `stanleyjobson` que comparar `johndoe` con `stanleyjobson`. Y lo mismo para la contraseña. |
|||
|
|||
De esa manera, usando `secrets.compare_digest()` en el código de tu aplicación, será seguro contra todo este rango de ataques de seguridad. |
|||
|
|||
### Devuelve el error |
|||
|
|||
Después de detectar que las credenciales son incorrectas, regresa un `HTTPException` con un código de estado 401 (el mismo que se devuelve cuando no se proporcionan credenciales) y agrega el header `WWW-Authenticate` para que el navegador muestre el prompt de inicio de sesión nuevamente: |
|||
|
|||
{* ../../docs_src/security/tutorial007_an_py39.py hl[26:30] *} |
@ -1,19 +1,19 @@ |
|||
# Seguridad Avanzada |
|||
|
|||
## Características Adicionales |
|||
## Funcionalidades Adicionales |
|||
|
|||
Hay algunas características adicionales para manejar la seguridad además de las que se tratan en el [Tutorial - Guía de Usuario: Seguridad](../../tutorial/security/index.md){.internal-link target=_blank}. |
|||
Hay algunas funcionalidades extra para manejar la seguridad aparte de las cubiertas en el [Tutorial - Guía del Usuario: Seguridad](../../tutorial/security/index.md){.internal-link target=_blank}. |
|||
|
|||
/// tip | Consejo |
|||
|
|||
Las siguientes secciones **no necesariamente son "avanzadas"**. |
|||
Las siguientes secciones **no son necesariamente "avanzadas"**. |
|||
|
|||
Y es posible que para tu caso de uso, la solución esté en alguna de ellas. |
|||
Y es posible que para tu caso de uso, la solución esté en una de ellas. |
|||
|
|||
/// |
|||
|
|||
## Leer primero el Tutorial |
|||
## Lee primero el Tutorial |
|||
|
|||
En las siguientes secciones asumimos que ya has leído el principal [Tutorial - Guía de Usuario: Seguridad](../../tutorial/security/index.md){.internal-link target=_blank}. |
|||
Las siguientes secciones asumen que ya leíste el [Tutorial - Guía del Usuario: Seguridad](../../tutorial/security/index.md){.internal-link target=_blank}. |
|||
|
|||
Están basadas en los mismos conceptos, pero permiten algunas funcionalidades adicionales. |
|||
Todas están basadas en los mismos conceptos, pero permiten algunas funcionalidades adicionales. |
|||
|
@ -0,0 +1,274 @@ |
|||
# Scopes de OAuth2 |
|||
|
|||
Puedes usar scopes de OAuth2 directamente con **FastAPI**, están integrados para funcionar de manera fluida. |
|||
|
|||
Esto te permitiría tener un sistema de permisos más detallado, siguiendo el estándar de OAuth2, integrado en tu aplicación OpenAPI (y la documentación de la API). |
|||
|
|||
OAuth2 con scopes es el mecanismo usado por muchos grandes proveedores de autenticación, como Facebook, Google, GitHub, Microsoft, Twitter, etc. Lo usan para proporcionar permisos específicos a usuarios y aplicaciones. |
|||
|
|||
Cada vez que te "logueas con" Facebook, Google, GitHub, Microsoft, Twitter, esa aplicación está usando OAuth2 con scopes. |
|||
|
|||
En esta sección verás cómo manejar autenticación y autorización con el mismo OAuth2 con scopes en tu aplicación de **FastAPI**. |
|||
|
|||
/// warning | Advertencia |
|||
|
|||
Esta es una sección más o menos avanzada. Si estás comenzando, puedes saltarla. |
|||
|
|||
No necesariamente necesitas scopes de OAuth2, y puedes manejar autenticación y autorización como quieras. |
|||
|
|||
Pero OAuth2 con scopes se puede integrar muy bien en tu API (con OpenAPI) y en la documentación de tu API. |
|||
|
|||
No obstante, tú aún impones esos scopes, o cualquier otro requisito de seguridad/autorización, como necesites, en tu código. |
|||
|
|||
En muchos casos, OAuth2 con scopes puede ser un exceso. |
|||
|
|||
Pero si sabes que lo necesitas, o tienes curiosidad, sigue leyendo. |
|||
|
|||
/// |
|||
|
|||
## Scopes de OAuth2 y OpenAPI |
|||
|
|||
La especificación de OAuth2 define "scopes" como una lista de strings separados por espacios. |
|||
|
|||
El contenido de cada uno de estos strings puede tener cualquier formato, pero no debe contener espacios. |
|||
|
|||
Estos scopes representan "permisos". |
|||
|
|||
En OpenAPI (por ejemplo, en la documentación de la API), puedes definir "esquemas de seguridad". |
|||
|
|||
Cuando uno de estos esquemas de seguridad usa OAuth2, también puedes declarar y usar scopes. |
|||
|
|||
Cada "scope" es solo un string (sin espacios). |
|||
|
|||
Normalmente se utilizan para declarar permisos de seguridad específicos, por ejemplo: |
|||
|
|||
* `users:read` o `users:write` son ejemplos comunes. |
|||
* `instagram_basic` es usado por Facebook / Instagram. |
|||
* `https://www.googleapis.com/auth/drive` es usado por Google. |
|||
|
|||
/// info | Información |
|||
|
|||
En OAuth2 un "scope" es solo un string que declara un permiso específico requerido. |
|||
|
|||
No importa si tiene otros caracteres como `:` o si es una URL. |
|||
|
|||
Esos detalles son específicos de la implementación. |
|||
|
|||
Para OAuth2 son solo strings. |
|||
|
|||
/// |
|||
|
|||
## Vista global |
|||
|
|||
Primero, echemos un vistazo rápido a las partes que cambian desde los ejemplos en el **Tutorial - User Guide** principal para [OAuth2 con Password (y hashing), Bearer con tokens JWT](../../tutorial/security/oauth2-jwt.md){.internal-link target=_blank}. Ahora usando scopes de OAuth2: |
|||
|
|||
{* ../../docs_src/security/tutorial005_an_py310.py hl[5,9,13,47,65,106,108:116,122:125,129:135,140,156] *} |
|||
|
|||
Ahora revisemos esos cambios paso a paso. |
|||
|
|||
## Esquema de seguridad OAuth2 |
|||
|
|||
El primer cambio es que ahora estamos declarando el esquema de seguridad OAuth2 con dos scopes disponibles, `me` y `items`. |
|||
|
|||
El parámetro `scopes` recibe un `dict` con cada scope como clave y la descripción como valor: |
|||
|
|||
{* ../../docs_src/security/tutorial005_an_py310.py hl[63:66] *} |
|||
|
|||
Como ahora estamos declarando esos scopes, aparecerán en la documentación de la API cuando inicies sesión/autorices. |
|||
|
|||
Y podrás seleccionar cuáles scopes quieres dar de acceso: `me` y `items`. |
|||
|
|||
Este es el mismo mecanismo utilizado cuando das permisos al iniciar sesión con Facebook, Google, GitHub, etc: |
|||
|
|||
<img src="/img/tutorial/security/image11.png"> |
|||
|
|||
## Token JWT con scopes |
|||
|
|||
Ahora, modifica la *path operation* del token para devolver los scopes solicitados. |
|||
|
|||
Todavía estamos usando el mismo `OAuth2PasswordRequestForm`. Incluye una propiedad `scopes` con una `list` de `str`, con cada scope que recibió en el request. |
|||
|
|||
Y devolvemos los scopes como parte del token JWT. |
|||
|
|||
/// danger | Peligro |
|||
|
|||
Para simplificar, aquí solo estamos añadiendo los scopes recibidos directamente al token. |
|||
|
|||
Pero en tu aplicación, por seguridad, deberías asegurarte de añadir solo los scopes que el usuario realmente puede tener, o los que has predefinido. |
|||
|
|||
/// |
|||
|
|||
{* ../../docs_src/security/tutorial005_an_py310.py hl[156] *} |
|||
|
|||
## Declarar scopes en *path operations* y dependencias |
|||
|
|||
Ahora declaramos que la *path operation* para `/users/me/items/` requiere el scope `items`. |
|||
|
|||
Para esto, importamos y usamos `Security` de `fastapi`. |
|||
|
|||
Puedes usar `Security` para declarar dependencias (igual que `Depends`), pero `Security` también recibe un parámetro `scopes` con una lista de scopes (strings). |
|||
|
|||
En este caso, pasamos una función de dependencia `get_current_active_user` a `Security` (de la misma manera que haríamos con `Depends`). |
|||
|
|||
Pero también pasamos una `list` de scopes, en este caso con solo un scope: `items` (podría tener más). |
|||
|
|||
Y la función de dependencia `get_current_active_user` también puede declarar sub-dependencias, no solo con `Depends` sino también con `Security`. Declarando su propia función de sub-dependencia (`get_current_user`), y más requisitos de scope. |
|||
|
|||
En este caso, requiere el scope `me` (podría requerir más de un scope). |
|||
|
|||
/// note | Nota |
|||
|
|||
No necesariamente necesitas añadir diferentes scopes en diferentes lugares. |
|||
|
|||
Lo estamos haciendo aquí para demostrar cómo **FastAPI** maneja scopes declarados en diferentes niveles. |
|||
|
|||
/// |
|||
|
|||
{* ../../docs_src/security/tutorial005_an_py310.py hl[5,140,171] *} |
|||
|
|||
/// info | Información Técnica |
|||
|
|||
`Security` es en realidad una subclase de `Depends`, y tiene solo un parámetro extra que veremos más adelante. |
|||
|
|||
Pero al usar `Security` en lugar de `Depends`, **FastAPI** sabrá que puede declarar scopes de seguridad, usarlos internamente y documentar la API con OpenAPI. |
|||
|
|||
Pero cuando importas `Query`, `Path`, `Depends`, `Security` y otros de `fastapi`, en realidad son funciones que devuelven clases especiales. |
|||
|
|||
/// |
|||
|
|||
## Usar `SecurityScopes` |
|||
|
|||
Ahora actualiza la dependencia `get_current_user`. |
|||
|
|||
Esta es la que usan las dependencias anteriores. |
|||
|
|||
Aquí es donde estamos usando el mismo esquema de OAuth2 que creamos antes, declarándolo como una dependencia: `oauth2_scheme`. |
|||
|
|||
Porque esta función de dependencia no tiene ningún requisito de scope en sí, podemos usar `Depends` con `oauth2_scheme`, no tenemos que usar `Security` cuando no necesitamos especificar scopes de seguridad. |
|||
|
|||
También declaramos un parámetro especial de tipo `SecurityScopes`, importado de `fastapi.security`. |
|||
|
|||
Esta clase `SecurityScopes` es similar a `Request` (`Request` se usó para obtener el objeto request directamente). |
|||
|
|||
{* ../../docs_src/security/tutorial005_an_py310.py hl[9,106] *} |
|||
|
|||
## Usar los `scopes` |
|||
|
|||
El parámetro `security_scopes` será del tipo `SecurityScopes`. |
|||
|
|||
Tendrá una propiedad `scopes` con una lista que contiene todos los scopes requeridos por sí mismo y por todas las dependencias que lo usan como sub-dependencia. Eso significa, todos los "dependientes"... esto podría sonar confuso, se explica de nuevo más abajo. |
|||
|
|||
El objeto `security_scopes` (de la clase `SecurityScopes`) también proporciona un atributo `scope_str` con un único string, que contiene esos scopes separados por espacios (lo vamos a usar). |
|||
|
|||
Creamos una `HTTPException` que podemos reutilizar (`raise`) más tarde en varios puntos. |
|||
|
|||
En esta excepción, incluimos los scopes requeridos (si los hay) como un string separado por espacios (usando `scope_str`). Ponemos ese string que contiene los scopes en el header `WWW-Authenticate` (esto es parte de la especificación). |
|||
|
|||
{* ../../docs_src/security/tutorial005_an_py310.py hl[106,108:116] *} |
|||
|
|||
## Verificar el `username` y la forma de los datos |
|||
|
|||
Verificamos que obtenemos un `username`, y extraemos los scopes. |
|||
|
|||
Y luego validamos esos datos con el modelo de Pydantic (capturando la excepción `ValidationError`), y si obtenemos un error leyendo el token JWT o validando los datos con Pydantic, lanzamos la `HTTPException` que creamos antes. |
|||
|
|||
Para eso, actualizamos el modelo de Pydantic `TokenData` con una nueva propiedad `scopes`. |
|||
|
|||
Al validar los datos con Pydantic podemos asegurarnos de que tenemos, por ejemplo, exactamente una `list` de `str` con los scopes y un `str` con el `username`. |
|||
|
|||
En lugar de, por ejemplo, un `dict`, o algo más, ya que podría romper la aplicación en algún punto posterior, haciéndolo un riesgo de seguridad. |
|||
|
|||
También verificamos que tenemos un usuario con ese username, y si no, lanzamos esa misma excepción que creamos antes. |
|||
|
|||
{* ../../docs_src/security/tutorial005_an_py310.py hl[47,117:128] *} |
|||
|
|||
## Verificar los `scopes` |
|||
|
|||
Ahora verificamos que todos los scopes requeridos, por esta dependencia y todos los dependientes (incluyendo *path operations*), estén incluidos en los scopes proporcionados en el token recibido, de lo contrario, lanzamos una `HTTPException`. |
|||
|
|||
Para esto, usamos `security_scopes.scopes`, que contiene una `list` con todos estos scopes como `str`. |
|||
|
|||
{* ../../docs_src/security/tutorial005_an_py310.py hl[129:135] *} |
|||
|
|||
## Árbol de dependencias y scopes |
|||
|
|||
Revisemos de nuevo este árbol de dependencias y los scopes. |
|||
|
|||
Como la dependencia `get_current_active_user` tiene como sub-dependencia a `get_current_user`, el scope `"me"` declarado en `get_current_active_user` se incluirá en la lista de scopes requeridos en el `security_scopes.scopes` pasado a `get_current_user`. |
|||
|
|||
La *path operation* en sí también declara un scope, `"items"`, por lo que esto también estará en la lista de `security_scopes.scopes` pasado a `get_current_user`. |
|||
|
|||
Así es como se ve la jerarquía de dependencias y scopes: |
|||
|
|||
* La *path operation* `read_own_items` tiene: |
|||
* Scopes requeridos `["items"]` con la dependencia: |
|||
* `get_current_active_user`: |
|||
* La función de dependencia `get_current_active_user` tiene: |
|||
* Scopes requeridos `["me"]` con la dependencia: |
|||
* `get_current_user`: |
|||
* La función de dependencia `get_current_user` tiene: |
|||
* No requiere scopes por sí misma. |
|||
* Una dependencia usando `oauth2_scheme`. |
|||
* Un parámetro `security_scopes` de tipo `SecurityScopes`: |
|||
* Este parámetro `security_scopes` tiene una propiedad `scopes` con una `list` que contiene todos estos scopes declarados arriba, por lo que: |
|||
* `security_scopes.scopes` contendrá `["me", "items"]` para la *path operation* `read_own_items`. |
|||
* `security_scopes.scopes` contendrá `["me"]` para la *path operation* `read_users_me`, porque está declarado en la dependencia `get_current_active_user`. |
|||
* `security_scopes.scopes` contendrá `[]` (nada) para la *path operation* `read_system_status`, porque no declaró ningún `Security` con `scopes`, y su dependencia, `get_current_user`, tampoco declara ningún `scopes`. |
|||
|
|||
/// tip | Consejo |
|||
|
|||
Lo importante y "mágico" aquí es que `get_current_user` tendrá una lista diferente de `scopes` para verificar para cada *path operation*. |
|||
|
|||
Todo depende de los `scopes` declarados en cada *path operation* y cada dependencia en el árbol de dependencias para esa *path operation* específica. |
|||
|
|||
/// |
|||
|
|||
## Más detalles sobre `SecurityScopes` |
|||
|
|||
Puedes usar `SecurityScopes` en cualquier punto, y en múltiples lugares, no tiene que ser en la dependencia "raíz". |
|||
|
|||
Siempre tendrá los scopes de seguridad declarados en las dependencias `Security` actuales y todos los dependientes para **esa específica** *path operation* y **ese específico** árbol de dependencias. |
|||
|
|||
Debido a que `SecurityScopes` tendrá todos los scopes declarados por dependientes, puedes usarlo para verificar que un token tiene los scopes requeridos en una función de dependencia central, y luego declarar diferentes requisitos de scope en diferentes *path operations*. |
|||
|
|||
Serán verificados independientemente para cada *path operation*. |
|||
|
|||
## Revisa |
|||
|
|||
Si abres la documentación de la API, puedes autenticarte y especificar qué scopes deseas autorizar. |
|||
|
|||
<img src="/img/tutorial/security/image11.png"> |
|||
|
|||
Si no seleccionas ningún scope, estarás "autenticado", pero cuando intentes acceder a `/users/me/` o `/users/me/items/` obtendrás un error diciendo que no tienes suficientes permisos. Aún podrás acceder a `/status/`. |
|||
|
|||
Y si seleccionas el scope `me` pero no el scope `items`, podrás acceder a `/users/me/` pero no a `/users/me/items/`. |
|||
|
|||
Eso es lo que pasaría a una aplicación de terceros que intentara acceder a una de estas *path operations* con un token proporcionado por un usuario, dependiendo de cuántos permisos el usuario otorgó a la aplicación. |
|||
|
|||
## Acerca de las integraciones de terceros |
|||
|
|||
En este ejemplo estamos usando el flujo de OAuth2 "password". |
|||
|
|||
Esto es apropiado cuando estamos iniciando sesión en nuestra propia aplicación, probablemente con nuestro propio frontend. |
|||
|
|||
Porque podemos confiar en ella para recibir el `username` y `password`, ya que la controlamos. |
|||
|
|||
Pero si estás construyendo una aplicación OAuth2 a la que otros se conectarían (es decir, si estás construyendo un proveedor de autenticación equivalente a Facebook, Google, GitHub, etc.) deberías usar uno de los otros flujos. |
|||
|
|||
El más común es el flujo implícito. |
|||
|
|||
El más seguro es el flujo de código, pero es más complejo de implementar ya que requiere más pasos. Como es más complejo, muchos proveedores terminan sugiriendo el flujo implícito. |
|||
|
|||
/// note | Nota |
|||
|
|||
Es común que cada proveedor de autenticación nombre sus flujos de una manera diferente, para hacerlos parte de su marca. |
|||
|
|||
Pero al final, están implementando el mismo estándar OAuth2. |
|||
|
|||
/// |
|||
|
|||
**FastAPI** incluye utilidades para todos estos flujos de autenticación OAuth2 en `fastapi.security.oauth2`. |
|||
|
|||
## `Security` en `dependencies` del decorador |
|||
|
|||
De la misma manera que puedes definir una `list` de `Depends` en el parámetro `dependencies` del decorador (como se explica en [Dependencias en decoradores de path operation](../../tutorial/dependencies/dependencies-in-path-operation-decorators.md){.internal-link target=_blank}), también podrías usar `Security` con `scopes` allí. |
@ -0,0 +1,346 @@ |
|||
# Configuraciones y Variables de Entorno |
|||
|
|||
En muchos casos, tu aplicación podría necesitar algunas configuraciones o ajustes externos, por ejemplo, claves secretas, credenciales de base de datos, credenciales para servicios de correo electrónico, etc. |
|||
|
|||
La mayoría de estas configuraciones son variables (pueden cambiar), como las URLs de bases de datos. Y muchas podrían ser sensibles, como los secretos. |
|||
|
|||
Por esta razón, es común proporcionarlas en variables de entorno que son leídas por la aplicación. |
|||
|
|||
/// tip | Consejo |
|||
|
|||
Para entender las variables de entorno, puedes leer [Variables de Entorno](../environment-variables.md){.internal-link target=_blank}. |
|||
|
|||
/// |
|||
|
|||
## Tipos y validación |
|||
|
|||
Estas variables de entorno solo pueden manejar strings de texto, ya que son externas a Python y tienen que ser compatibles con otros programas y el resto del sistema (e incluso con diferentes sistemas operativos, como Linux, Windows, macOS). |
|||
|
|||
Eso significa que cualquier valor leído en Python desde una variable de entorno será un `str`, y cualquier conversión a un tipo diferente o cualquier validación tiene que hacerse en código. |
|||
|
|||
## Pydantic `Settings` |
|||
|
|||
Afortunadamente, Pydantic proporciona una gran utilidad para manejar estas configuraciones provenientes de variables de entorno con <a href="https://docs.pydantic.dev/latest/concepts/pydantic_settings/" class="external-link" target="_blank">Pydantic: Settings management</a>. |
|||
|
|||
### Instalar `pydantic-settings` |
|||
|
|||
Primero, asegúrate de crear tu [entorno virtual](../virtual-environments.md){.internal-link target=_blank}, actívalo y luego instala el paquete `pydantic-settings`: |
|||
|
|||
<div class="termy"> |
|||
|
|||
```console |
|||
$ pip install pydantic-settings |
|||
---> 100% |
|||
``` |
|||
|
|||
</div> |
|||
|
|||
También viene incluido cuando instalas los extras `all` con: |
|||
|
|||
<div class="termy"> |
|||
|
|||
```console |
|||
$ pip install "fastapi[all]" |
|||
---> 100% |
|||
``` |
|||
|
|||
</div> |
|||
|
|||
/// info | Información |
|||
|
|||
En Pydantic v1 venía incluido con el paquete principal. Ahora se distribuye como este paquete independiente para que puedas elegir si instalarlo o no si no necesitas esa funcionalidad. |
|||
|
|||
/// |
|||
|
|||
### Crear el objeto `Settings` |
|||
|
|||
Importa `BaseSettings` de Pydantic y crea una sub-clase, muy similar a un modelo de Pydantic. |
|||
|
|||
De la misma forma que con los modelos de Pydantic, declaras atributos de clase con anotaciones de tipos, y posiblemente, valores por defecto. |
|||
|
|||
Puedes usar todas las mismas funcionalidades de validación y herramientas que usas para los modelos de Pydantic, como diferentes tipos de datos y validaciones adicionales con `Field()`. |
|||
|
|||
//// tab | Pydantic v2 |
|||
|
|||
{* ../../docs_src/settings/tutorial001.py hl[2,5:8,11] *} |
|||
|
|||
//// |
|||
|
|||
//// tab | Pydantic v1 |
|||
|
|||
/// info | Información |
|||
|
|||
En Pydantic v1 importarías `BaseSettings` directamente desde `pydantic` en lugar de desde `pydantic_settings`. |
|||
|
|||
/// |
|||
|
|||
{* ../../docs_src/settings/tutorial001_pv1.py hl[2,5:8,11] *} |
|||
|
|||
//// |
|||
|
|||
/// tip | Consejo |
|||
|
|||
Si quieres algo rápido para copiar y pegar, no uses este ejemplo, usa el último más abajo. |
|||
|
|||
/// |
|||
|
|||
Luego, cuando creas una instance de esa clase `Settings` (en este caso, en el objeto `settings`), Pydantic leerá las variables de entorno de una manera indiferente a mayúsculas y minúsculas, por lo que una variable en mayúsculas `APP_NAME` aún será leída para el atributo `app_name`. |
|||
|
|||
Luego convertirá y validará los datos. Así que, cuando uses ese objeto `settings`, tendrás datos de los tipos que declaraste (por ejemplo, `items_per_user` será un `int`). |
|||
|
|||
### Usar el `settings` |
|||
|
|||
Luego puedes usar el nuevo objeto `settings` en tu aplicación: |
|||
|
|||
{* ../../docs_src/settings/tutorial001.py hl[18:20] *} |
|||
|
|||
### Ejecutar el servidor |
|||
|
|||
Luego, ejecutarías el servidor pasando las configuraciones como variables de entorno, por ejemplo, podrías establecer un `ADMIN_EMAIL` y `APP_NAME` con: |
|||
|
|||
<div class="termy"> |
|||
|
|||
```console |
|||
$ ADMIN_EMAIL="[email protected]" APP_NAME="ChimichangApp" fastapi run main.py |
|||
|
|||
<span style="color: green;">INFO</span>: Uvicorn running on http://127.0.0.1:8000 (Press CTRL+C to quit) |
|||
``` |
|||
|
|||
</div> |
|||
|
|||
/// tip | Consejo |
|||
|
|||
Para establecer múltiples variables de entorno para un solo comando, simplemente sepáralas con un espacio y ponlas todas antes del comando. |
|||
|
|||
/// |
|||
|
|||
Y luego la configuración `admin_email` se establecería en `"[email protected]"`. |
|||
|
|||
El `app_name` sería `"ChimichangApp"`. |
|||
|
|||
Y el `items_per_user` mantendría su valor por defecto de `50`. |
|||
|
|||
## Configuraciones en otro módulo |
|||
|
|||
Podrías poner esas configuraciones en otro archivo de módulo como viste en [Aplicaciones Más Grandes - Múltiples Archivos](../tutorial/bigger-applications.md){.internal-link target=_blank}. |
|||
|
|||
Por ejemplo, podrías tener un archivo `config.py` con: |
|||
|
|||
{* ../../docs_src/settings/app01/config.py *} |
|||
|
|||
Y luego usarlo en un archivo `main.py`: |
|||
|
|||
{* ../../docs_src/settings/app01/main.py hl[3,11:13] *} |
|||
|
|||
/// tip | Consejo |
|||
|
|||
También necesitarías un archivo `__init__.py` como viste en [Aplicaciones Más Grandes - Múltiples Archivos](../tutorial/bigger-applications.md){.internal-link target=_blank}. |
|||
|
|||
/// |
|||
|
|||
## Configuraciones en una dependencia |
|||
|
|||
En algunas ocasiones podría ser útil proporcionar las configuraciones desde una dependencia, en lugar de tener un objeto global con `settings` que se use en todas partes. |
|||
|
|||
Esto podría ser especialmente útil durante las pruebas, ya que es muy fácil sobrescribir una dependencia con tus propias configuraciones personalizadas. |
|||
|
|||
### El archivo de configuración |
|||
|
|||
Proveniente del ejemplo anterior, tu archivo `config.py` podría verse como: |
|||
|
|||
{* ../../docs_src/settings/app02/config.py hl[10] *} |
|||
|
|||
Nota que ahora no creamos una instance por defecto `settings = Settings()`. |
|||
|
|||
### El archivo principal de la app |
|||
|
|||
Ahora creamos una dependencia que devuelve un nuevo `config.Settings()`. |
|||
|
|||
{* ../../docs_src/settings/app02_an_py39/main.py hl[6,12:13] *} |
|||
|
|||
/// tip | Consejo |
|||
|
|||
Hablaremos del `@lru_cache` en un momento. |
|||
|
|||
Por ahora puedes asumir que `get_settings()` es una función normal. |
|||
|
|||
/// |
|||
|
|||
Y luego podemos requerirlo desde la *path operation function* como una dependencia y usarlo donde lo necesitemos. |
|||
|
|||
{* ../../docs_src/settings/app02_an_py39/main.py hl[17,19:21] *} |
|||
|
|||
### Configuraciones y pruebas |
|||
|
|||
Luego sería muy fácil proporcionar un objeto de configuraciones diferente durante las pruebas al sobrescribir una dependencia para `get_settings`: |
|||
|
|||
{* ../../docs_src/settings/app02/test_main.py hl[9:10,13,21] *} |
|||
|
|||
En la dependencia sobreescrita establecemos un nuevo valor para el `admin_email` al crear el nuevo objeto `Settings`, y luego devolvemos ese nuevo objeto. |
|||
|
|||
Luego podemos probar que se está usando. |
|||
|
|||
## Leer un archivo `.env` |
|||
|
|||
Si tienes muchas configuraciones que posiblemente cambien mucho, tal vez en diferentes entornos, podría ser útil ponerlos en un archivo y luego leerlos desde allí como si fueran variables de entorno. |
|||
|
|||
Esta práctica es lo suficientemente común que tiene un nombre, estas variables de entorno generalmente se colocan en un archivo `.env`, y el archivo se llama un "dotenv". |
|||
|
|||
/// tip | Consejo |
|||
|
|||
Un archivo que comienza con un punto (`.`) es un archivo oculto en sistemas tipo Unix, como Linux y macOS. |
|||
|
|||
Pero un archivo dotenv realmente no tiene que tener ese nombre exacto. |
|||
|
|||
/// |
|||
|
|||
Pydantic tiene soporte para leer desde estos tipos de archivos usando un paquete externo. Puedes leer más en <a href="https://docs.pydantic.dev/latest/concepts/pydantic_settings/#dotenv-env-support" class="external-link" target="_blank">Pydantic Settings: Dotenv (.env) support</a>. |
|||
|
|||
/// tip | Consejo |
|||
|
|||
Para que esto funcione, necesitas `pip install python-dotenv`. |
|||
|
|||
/// |
|||
|
|||
### El archivo `.env` |
|||
|
|||
Podrías tener un archivo `.env` con: |
|||
|
|||
```bash |
|||
ADMIN_EMAIL="[email protected]" |
|||
APP_NAME="ChimichangApp" |
|||
``` |
|||
|
|||
### Leer configuraciones desde `.env` |
|||
|
|||
Y luego actualizar tu `config.py` con: |
|||
|
|||
//// tab | Pydantic v2 |
|||
|
|||
{* ../../docs_src/settings/app03_an/config.py hl[9] *} |
|||
|
|||
/// tip | Consejo |
|||
|
|||
El atributo `model_config` se usa solo para configuración de Pydantic. Puedes leer más en <a href="https://docs.pydantic.dev/latest/concepts/config/" class="external-link" target="_blank">Pydantic: Concepts: Configuration</a>. |
|||
|
|||
/// |
|||
|
|||
//// |
|||
|
|||
//// tab | Pydantic v1 |
|||
|
|||
{* ../../docs_src/settings/app03_an/config_pv1.py hl[9:10] *} |
|||
|
|||
/// tip | Consejo |
|||
|
|||
La clase `Config` se usa solo para configuración de Pydantic. Puedes leer más en <a href="https://docs.pydantic.dev/1.10/usage/model_config/" class="external-link" target="_blank">Pydantic Model Config</a>. |
|||
|
|||
/// |
|||
|
|||
//// |
|||
|
|||
/// info | Información |
|||
|
|||
En la versión 1 de Pydantic la configuración se hacía en una clase interna `Config`, en la versión 2 de Pydantic se hace en un atributo `model_config`. Este atributo toma un `dict`, y para obtener autocompletado y errores en línea, puedes importar y usar `SettingsConfigDict` para definir ese `dict`. |
|||
|
|||
/// |
|||
|
|||
Aquí definimos la configuración `env_file` dentro de tu clase Pydantic `Settings`, y establecemos el valor en el nombre del archivo con el archivo dotenv que queremos usar. |
|||
|
|||
### Creando el `Settings` solo una vez con `lru_cache` |
|||
|
|||
Leer un archivo desde el disco es normalmente una operación costosa (lenta), por lo que probablemente quieras hacerlo solo una vez y luego reutilizar el mismo objeto de configuraciones, en lugar de leerlo para cada request. |
|||
|
|||
Pero cada vez que hacemos: |
|||
|
|||
```Python |
|||
Settings() |
|||
``` |
|||
|
|||
se crearía un nuevo objeto `Settings`, y al crearse leería el archivo `.env` nuevamente. |
|||
|
|||
Si la función de dependencia fuera simplemente así: |
|||
|
|||
```Python |
|||
def get_settings(): |
|||
return Settings() |
|||
``` |
|||
|
|||
crearíamos ese objeto para cada request, y estaríamos leyendo el archivo `.env` para cada request. ⚠️ |
|||
|
|||
Pero como estamos usando el decorador `@lru_cache` encima, el objeto `Settings` se creará solo una vez, la primera vez que se llame. ✔️ |
|||
|
|||
{* ../../docs_src/settings/app03_an_py39/main.py hl[1,11] *} |
|||
|
|||
Entonces, para cualquier llamada subsiguiente de `get_settings()` en las dependencias de los próximos requests, en lugar de ejecutar el código interno de `get_settings()` y crear un nuevo objeto `Settings`, devolverá el mismo objeto que fue devuelto en la primera llamada, una y otra vez. |
|||
|
|||
#### Detalles Técnicos de `lru_cache` |
|||
|
|||
`@lru_cache` modifica la función que decora para devolver el mismo valor que se devolvió la primera vez, en lugar de calcularlo nuevamente, ejecutando el código de la función cada vez. |
|||
|
|||
Así que la función debajo se ejecutará una vez por cada combinación de argumentos. Y luego, los valores devueltos por cada una de esas combinaciones de argumentos se utilizarán una y otra vez cada vez que la función sea llamada con exactamente la misma combinación de argumentos. |
|||
|
|||
Por ejemplo, si tienes una función: |
|||
|
|||
```Python |
|||
@lru_cache |
|||
def say_hi(name: str, salutation: str = "Ms."): |
|||
return f"Hello {salutation} {name}" |
|||
``` |
|||
|
|||
tu programa podría ejecutarse así: |
|||
|
|||
```mermaid |
|||
sequenceDiagram |
|||
|
|||
participant code as Código |
|||
participant function as say_hi() |
|||
participant execute as Ejecutar función |
|||
|
|||
rect rgba(0, 255, 0, .1) |
|||
code ->> function: say_hi(name="Camila") |
|||
function ->> execute: ejecutar código de la función |
|||
execute ->> code: devolver el resultado |
|||
end |
|||
|
|||
rect rgba(0, 255, 255, .1) |
|||
code ->> function: say_hi(name="Camila") |
|||
function ->> code: devolver resultado almacenado |
|||
end |
|||
|
|||
rect rgba(0, 255, 0, .1) |
|||
code ->> function: say_hi(name="Rick") |
|||
function ->> execute: ejecutar código de la función |
|||
execute ->> code: devolver el resultado |
|||
end |
|||
|
|||
rect rgba(0, 255, 0, .1) |
|||
code ->> function: say_hi(name="Rick", salutation="Mr.") |
|||
function ->> execute: ejecutar código de la función |
|||
execute ->> code: devolver el resultado |
|||
end |
|||
|
|||
rect rgba(0, 255, 255, .1) |
|||
code ->> function: say_hi(name="Rick") |
|||
function ->> code: devolver resultado almacenado |
|||
end |
|||
|
|||
rect rgba(0, 255, 255, .1) |
|||
code ->> function: say_hi(name="Camila") |
|||
function ->> code: devolver resultado almacenado |
|||
end |
|||
``` |
|||
|
|||
En el caso de nuestra dependencia `get_settings()`, la función ni siquiera toma argumentos, por lo que siempre devolverá el mismo valor. |
|||
|
|||
De esa manera, se comporta casi como si fuera solo una variable global. Pero como usa una función de dependencia, entonces podemos sobrescribirla fácilmente para las pruebas. |
|||
|
|||
`@lru_cache` es parte de `functools`, que es parte del library estándar de Python, puedes leer más sobre él en las <a href="https://docs.python.org/3/library/functools.html#functools.lru_cache" class="external-link" target="_blank">docs de Python para `@lru_cache`</a>. |
|||
|
|||
## Resumen |
|||
|
|||
Puedes usar Pydantic Settings para manejar las configuraciones o ajustes de tu aplicación, con todo el poder de los modelos de Pydantic. |
|||
|
|||
* Al usar una dependencia, puedes simplificar las pruebas. |
|||
* Puedes usar archivos `.env` con él. |
|||
* Usar `@lru_cache` te permite evitar leer el archivo dotenv una y otra vez para cada request, mientras te permite sobrescribirlo durante las pruebas. |
@ -0,0 +1,67 @@ |
|||
# Sub Aplicaciones - Mounts |
|||
|
|||
Si necesitas tener dos aplicaciones de **FastAPI** independientes, cada una con su propio OpenAPI independiente y su propia interfaz de docs, puedes tener una aplicación principal y "montar" una (o más) sub-aplicación(es). |
|||
|
|||
## Montar una aplicación **FastAPI** |
|||
|
|||
"Montar" significa añadir una aplicación completamente "independiente" en un path específico, que luego se encarga de manejar todo bajo ese path, con las _path operations_ declaradas en esa sub-aplicación. |
|||
|
|||
### Aplicación de nivel superior |
|||
|
|||
Primero, crea la aplicación principal de nivel superior de **FastAPI**, y sus *path operations*: |
|||
|
|||
{* ../../docs_src/sub_applications/tutorial001.py hl[3, 6:8] *} |
|||
|
|||
### Sub-aplicación |
|||
|
|||
Luego, crea tu sub-aplicación, y sus *path operations*. |
|||
|
|||
Esta sub-aplicación es solo otra aplicación estándar de FastAPI, pero es la que se "montará": |
|||
|
|||
{* ../../docs_src/sub_applications/tutorial001.py hl[11, 14:16] *} |
|||
|
|||
### Montar la sub-aplicación |
|||
|
|||
En tu aplicación de nivel superior, `app`, monta la sub-aplicación, `subapi`. |
|||
|
|||
En este caso, se montará en el path `/subapi`: |
|||
|
|||
{* ../../docs_src/sub_applications/tutorial001.py hl[11, 19] *} |
|||
|
|||
### Revisa la documentación automática de la API |
|||
|
|||
Ahora, ejecuta el comando `fastapi` con tu archivo: |
|||
|
|||
<div class="termy"> |
|||
|
|||
```console |
|||
$ fastapi dev main.py |
|||
|
|||
<span style="color: green;">INFO</span>: Uvicorn running on http://127.0.0.1:8000 (Press CTRL+C to quit) |
|||
``` |
|||
|
|||
</div> |
|||
|
|||
Y abre la documentación en <a href="http://127.0.0.1:8000/docs" class="external-link" target="_blank">http://127.0.0.1:8000/docs</a>. |
|||
|
|||
Verás la documentación automática de la API para la aplicación principal, incluyendo solo sus propias _path operations_: |
|||
|
|||
<img src="/img/tutorial/sub-applications/image01.png"> |
|||
|
|||
Y luego, abre la documentación para la sub-aplicación, en <a href="http://127.0.0.1:8000/subapi/docs" class="external-link" target="_blank">http://127.0.0.1:8000/subapi/docs</a>. |
|||
|
|||
Verás la documentación automática de la API para la sub-aplicación, incluyendo solo sus propias _path operations_, todas bajo el prefijo correcto del sub-path `/subapi`: |
|||
|
|||
<img src="/img/tutorial/sub-applications/image02.png"> |
|||
|
|||
Si intentas interactuar con cualquiera de las dos interfaces de usuario, funcionarán correctamente, porque el navegador podrá comunicarse con cada aplicación o sub-aplicación específica. |
|||
|
|||
### Detalles Técnicos: `root_path` |
|||
|
|||
Cuando montas una sub-aplicación como se describe arriba, FastAPI se encargará de comunicar el path de montaje para la sub-aplicación usando un mecanismo de la especificación ASGI llamado `root_path`. |
|||
|
|||
De esa manera, la sub-aplicación sabrá usar ese prefijo de path para la interfaz de documentación. |
|||
|
|||
Y la sub-aplicación también podría tener sus propias sub-aplicaciones montadas y todo funcionaría correctamente, porque FastAPI maneja todos estos `root_path`s automáticamente. |
|||
|
|||
Aprenderás más sobre el `root_path` y cómo usarlo explícitamente en la sección sobre [Detrás de un Proxy](behind-a-proxy.md){.internal-link target=_blank}. |
@ -0,0 +1,126 @@ |
|||
# Plantillas |
|||
|
|||
Puedes usar cualquier motor de plantillas que desees con **FastAPI**. |
|||
|
|||
Una elección común es Jinja2, el mismo que usa Flask y otras herramientas. |
|||
|
|||
Hay utilidades para configurarlo fácilmente que puedes usar directamente en tu aplicación de **FastAPI** (proporcionadas por Starlette). |
|||
|
|||
## Instalar dependencias |
|||
|
|||
Asegúrate de crear un [entorno virtual](../virtual-environments.md){.internal-link target=_blank}, activarlo e instalar `jinja2`: |
|||
|
|||
<div class="termy"> |
|||
|
|||
```console |
|||
$ pip install jinja2 |
|||
|
|||
---> 100% |
|||
``` |
|||
|
|||
</div> |
|||
|
|||
## Usando `Jinja2Templates` |
|||
|
|||
* Importa `Jinja2Templates`. |
|||
* Crea un objeto `templates` que puedas reutilizar más tarde. |
|||
* Declara un parámetro `Request` en la *path operation* que devolverá una plantilla. |
|||
* Usa los `templates` que creaste para renderizar y devolver un `TemplateResponse`, pasa el nombre de la plantilla, el objeto de request, y un diccionario "context" con pares clave-valor que se usarán dentro de la plantilla Jinja2. |
|||
|
|||
{* ../../docs_src/templates/tutorial001.py hl[4,11,15:18] *} |
|||
|
|||
/// note | Nota |
|||
|
|||
Antes de FastAPI 0.108.0, Starlette 0.29.0, el `name` era el primer parámetro. |
|||
|
|||
Además, antes de eso, en versiones anteriores, el objeto `request` se pasaba como parte de los pares clave-valor en el contexto para Jinja2. |
|||
|
|||
/// |
|||
|
|||
/// tip | Consejo |
|||
|
|||
Al declarar `response_class=HTMLResponse`, la interfaz de usuario de la documentación podrá saber que el response será HTML. |
|||
|
|||
/// |
|||
|
|||
/// note | Nota Técnica |
|||
|
|||
También podrías usar `from starlette.templating import Jinja2Templates`. |
|||
|
|||
**FastAPI** proporciona el mismo `starlette.templating` como `fastapi.templating`, solo como una conveniencia para ti, el desarrollador. Pero la mayoría de los responses disponibles vienen directamente de Starlette. Lo mismo con `Request` y `StaticFiles`. |
|||
|
|||
/// |
|||
|
|||
## Escribiendo plantillas |
|||
|
|||
Luego puedes escribir una plantilla en `templates/item.html` con, por ejemplo: |
|||
|
|||
```jinja hl_lines="7" |
|||
{!../../docs_src/templates/templates/item.html!} |
|||
``` |
|||
|
|||
### Valores de Contexto de la Plantilla |
|||
|
|||
En el HTML que contiene: |
|||
|
|||
{% raw %} |
|||
|
|||
```jinja |
|||
Item ID: {{ id }} |
|||
``` |
|||
|
|||
{% endraw %} |
|||
|
|||
...mostrará el `id` tomado del `dict` de "contexto" que pasaste: |
|||
|
|||
```Python |
|||
{"id": id} |
|||
``` |
|||
|
|||
Por ejemplo, con un ID de `42`, esto se renderizaría como: |
|||
|
|||
```html |
|||
Item ID: 42 |
|||
``` |
|||
|
|||
### Argumentos de la Plantilla `url_for` |
|||
|
|||
También puedes usar `url_for()` dentro de la plantilla, toma como argumentos los mismos que usaría tu *path operation function*. |
|||
|
|||
Entonces, la sección con: |
|||
|
|||
{% raw %} |
|||
|
|||
```jinja |
|||
<a href="{{ url_for('read_item', id=id) }}"> |
|||
``` |
|||
|
|||
{% endraw %} |
|||
|
|||
...generará un enlace hacia la misma URL que manejaría la *path operation function* `read_item(id=id)`. |
|||
|
|||
Por ejemplo, con un ID de `42`, esto se renderizaría como: |
|||
|
|||
```html |
|||
<a href="/items/42"> |
|||
``` |
|||
|
|||
## Plantillas y archivos estáticos |
|||
|
|||
También puedes usar `url_for()` dentro de la plantilla, y usarlo, por ejemplo, con los `StaticFiles` que montaste con el `name="static"`. |
|||
|
|||
```jinja hl_lines="4" |
|||
{!../../docs_src/templates/templates/item.html!} |
|||
``` |
|||
|
|||
En este ejemplo, enlazaría a un archivo CSS en `static/styles.css` con: |
|||
|
|||
```CSS hl_lines="4" |
|||
{!../../docs_src/templates/static/styles.css!} |
|||
``` |
|||
|
|||
Y porque estás usando `StaticFiles`, ese archivo CSS sería servido automáticamente por tu aplicación de **FastAPI** en la URL `/static/styles.css`. |
|||
|
|||
## Más detalles |
|||
|
|||
Para más detalles, incluyendo cómo testear plantillas, revisa <a href="https://www.starlette.io/templates/" class="external-link" target="_blank">la documentación de Starlette sobre plantillas</a>. |
@ -0,0 +1,53 @@ |
|||
# Probando Dependencias con Overrides |
|||
|
|||
## Sobrescribir dependencias durante las pruebas |
|||
|
|||
Hay algunos escenarios donde podrías querer sobrescribir una dependencia durante las pruebas. |
|||
|
|||
No quieres que la dependencia original se ejecute (ni ninguna de las sub-dependencias que pueda tener). |
|||
|
|||
En cambio, quieres proporcionar una dependencia diferente que se usará solo durante las pruebas (posiblemente solo algunas pruebas específicas), y que proporcionará un valor que pueda ser usado donde se usó el valor de la dependencia original. |
|||
|
|||
### Casos de uso: servicio externo |
|||
|
|||
Un ejemplo podría ser que tienes un proveedor de autenticación externo al que necesitas llamar. |
|||
|
|||
Le envías un token y te devuelve un usuario autenticado. |
|||
|
|||
Este proveedor podría estar cobrándote por cada request, y llamarlo podría tomar más tiempo adicional que si tuvieras un usuario de prueba fijo para los tests. |
|||
|
|||
Probablemente quieras probar el proveedor externo una vez, pero no necesariamente llamarlo para cada test que se realice. |
|||
|
|||
En este caso, puedes sobrescribir la dependencia que llama a ese proveedor y usar una dependencia personalizada que devuelva un usuario de prueba, solo para tus tests. |
|||
|
|||
### Usa el atributo `app.dependency_overrides` |
|||
|
|||
Para estos casos, tu aplicación **FastAPI** tiene un atributo `app.dependency_overrides`, es un simple `dict`. |
|||
|
|||
Para sobrescribir una dependencia para las pruebas, colocas como clave la dependencia original (una función), y como valor, tu dependencia para sobreescribir (otra función). |
|||
|
|||
Y entonces **FastAPI** llamará a esa dependencia para sobreescribir en lugar de la dependencia original. |
|||
|
|||
{* ../../docs_src/dependency_testing/tutorial001_an_py310.py hl[26:27,30] *} |
|||
|
|||
/// tip | Consejo |
|||
|
|||
Puedes sobreescribir una dependencia utilizada en cualquier lugar de tu aplicación **FastAPI**. |
|||
|
|||
La dependencia original podría ser utilizada en una *path operation function*, un *path operation decorator* (cuando no usas el valor de retorno), una llamada a `.include_router()`, etc. |
|||
|
|||
FastAPI todavía podrá sobrescribirla. |
|||
|
|||
/// |
|||
|
|||
Entonces puedes restablecer las dependencias sobreescritas configurando `app.dependency_overrides` para que sea un `dict` vacío: |
|||
|
|||
```Python |
|||
app.dependency_overrides = {} |
|||
``` |
|||
|
|||
/// tip | Consejo |
|||
|
|||
Si quieres sobrescribir una dependencia solo durante algunos tests, puedes establecer la sobrescritura al inicio del test (dentro de la función del test) y restablecerla al final (al final de la función del test). |
|||
|
|||
/// |
@ -0,0 +1,5 @@ |
|||
# Testing Events: startup - shutdown |
|||
|
|||
Cuando necesitas que tus manejadores de eventos (`startup` y `shutdown`) se ejecuten en tus tests, puedes usar el `TestClient` con un statement `with`: |
|||
|
|||
{* ../../docs_src/app_testing/tutorial003.py hl[9:12,20:24] *} |
@ -0,0 +1,13 @@ |
|||
# Probando WebSockets |
|||
|
|||
Puedes usar el mismo `TestClient` para probar WebSockets. |
|||
|
|||
Para esto, usas el `TestClient` en un statement `with`, conectándote al WebSocket: |
|||
|
|||
{* ../../docs_src/app_testing/tutorial002.py hl[27:31] *} |
|||
|
|||
/// note | Nota |
|||
|
|||
Para más detalles, revisa la documentación de Starlette sobre <a href="https://www.starlette.io/testclient/#testing-websocket-sessions" class="external-link" target="_blank">probando sesiones WebSocket</a>. |
|||
|
|||
/// |
@ -0,0 +1,56 @@ |
|||
# Usar el Request Directamente |
|||
|
|||
Hasta ahora, has estado declarando las partes del request que necesitas con sus tipos. |
|||
|
|||
Tomando datos de: |
|||
|
|||
* El path como parámetros. |
|||
* Headers. |
|||
* Cookies. |
|||
* etc. |
|||
|
|||
Y al hacerlo, **FastAPI** está validando esos datos, convirtiéndolos y generando documentación para tu API automáticamente. |
|||
|
|||
Pero hay situaciones donde podrías necesitar acceder al objeto `Request` directamente. |
|||
|
|||
## Detalles sobre el objeto `Request` |
|||
|
|||
Como **FastAPI** es en realidad **Starlette** por debajo, con una capa de varias herramientas encima, puedes usar el objeto <a href="https://www.starlette.io/requests/" class="external-link" target="_blank">`Request`</a> de Starlette directamente cuando lo necesites. |
|||
|
|||
También significa que si obtienes datos del objeto `Request` directamente (por ejemplo, leyendo el cuerpo) no serán validados, convertidos o documentados (con OpenAPI, para la interfaz automática de usuario de la API) por FastAPI. |
|||
|
|||
Aunque cualquier otro parámetro declarado normalmente (por ejemplo, el cuerpo con un modelo de Pydantic) seguiría siendo validado, convertido, anotado, etc. |
|||
|
|||
Pero hay casos específicos donde es útil obtener el objeto `Request`. |
|||
|
|||
## Usa el objeto `Request` directamente |
|||
|
|||
Imaginemos que quieres obtener la dirección IP/host del cliente dentro de tu *path operation function*. |
|||
|
|||
Para eso necesitas acceder al request directamente. |
|||
|
|||
{* ../../docs_src/using_request_directly/tutorial001.py hl[1,7:8] *} |
|||
|
|||
Al declarar un parámetro de *path operation function* con el tipo siendo `Request`, **FastAPI** sabrá pasar el `Request` en ese parámetro. |
|||
|
|||
/// tip | Consejo |
|||
|
|||
Nota que en este caso, estamos declarando un parámetro de path además del parámetro del request. |
|||
|
|||
Así que, el parámetro de path será extraído, validado, convertido al tipo especificado y anotado con OpenAPI. |
|||
|
|||
De la misma manera, puedes declarar cualquier otro parámetro como normalmente, y adicionalmente, obtener también el `Request`. |
|||
|
|||
/// |
|||
|
|||
## Documentación de `Request` |
|||
|
|||
Puedes leer más detalles sobre el <a href="https://www.starlette.io/requests/" class="external-link" target="_blank">objeto `Request` en el sitio de documentación oficial de Starlette</a>. |
|||
|
|||
/// note | Detalles Técnicos |
|||
|
|||
Podrías también usar `from starlette.requests import Request`. |
|||
|
|||
**FastAPI** lo proporciona directamente solo como conveniencia para ti, el desarrollador. Pero viene directamente de Starlette. |
|||
|
|||
/// |
@ -0,0 +1,186 @@ |
|||
# WebSockets |
|||
|
|||
Puedes usar <a href="https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API" class="external-link" target="_blank">WebSockets</a> con **FastAPI**. |
|||
|
|||
## Instalar `WebSockets` |
|||
|
|||
Asegúrate de crear un [entorno virtual](../virtual-environments.md){.internal-link target=_blank}, activarlo e instalar `websockets`: |
|||
|
|||
<div class="termy"> |
|||
|
|||
```console |
|||
$ pip install websockets |
|||
|
|||
---> 100% |
|||
``` |
|||
|
|||
</div> |
|||
|
|||
## Cliente WebSockets |
|||
|
|||
### En producción |
|||
|
|||
En tu sistema de producción, probablemente tengas un frontend creado con un framework moderno como React, Vue.js o Angular. |
|||
|
|||
Y para comunicarte usando WebSockets con tu backend probablemente usarías las utilidades de tu frontend. |
|||
|
|||
O podrías tener una aplicación móvil nativa que se comunica con tu backend de WebSocket directamente, en código nativo. |
|||
|
|||
O podrías tener alguna otra forma de comunicarte con el endpoint de WebSocket. |
|||
|
|||
--- |
|||
|
|||
Pero para este ejemplo, usaremos un documento HTML muy simple con algo de JavaScript, todo dentro de un string largo. |
|||
|
|||
Esto, por supuesto, no es lo ideal y no lo usarías para producción. |
|||
|
|||
En producción tendrías una de las opciones anteriores. |
|||
|
|||
Pero es la forma más sencilla de enfocarse en el lado del servidor de WebSockets y tener un ejemplo funcional: |
|||
|
|||
{* ../../docs_src/websockets/tutorial001.py hl[2,6:38,41:43] *} |
|||
|
|||
## Crear un `websocket` |
|||
|
|||
En tu aplicación de **FastAPI**, crea un `websocket`: |
|||
|
|||
{* ../../docs_src/websockets/tutorial001.py hl[1,46:47] *} |
|||
|
|||
/// note | Detalles Técnicos |
|||
|
|||
También podrías usar `from starlette.websockets import WebSocket`. |
|||
|
|||
**FastAPI** proporciona el mismo `WebSocket` directamente solo como una conveniencia para ti, el desarrollador. Pero viene directamente de Starlette. |
|||
|
|||
/// |
|||
|
|||
## Esperar mensajes y enviar mensajes |
|||
|
|||
En tu ruta de WebSocket puedes `await` para recibir mensajes y enviar mensajes. |
|||
|
|||
{* ../../docs_src/websockets/tutorial001.py hl[48:52] *} |
|||
|
|||
Puedes recibir y enviar datos binarios, de texto y JSON. |
|||
|
|||
## Pruébalo |
|||
|
|||
Si tu archivo se llama `main.py`, ejecuta tu aplicación con: |
|||
|
|||
<div class="termy"> |
|||
|
|||
```console |
|||
$ fastapi dev main.py |
|||
|
|||
<span style="color: green;">INFO</span>: Uvicorn running on http://127.0.0.1:8000 (Press CTRL+C to quit) |
|||
``` |
|||
|
|||
</div> |
|||
|
|||
Abre tu navegador en <a href="http://127.0.0.1:8000" class="external-link" target="_blank">http://127.0.0.1:8000</a>. |
|||
|
|||
Verás una página simple como: |
|||
|
|||
<img src="/img/tutorial/websockets/image01.png"> |
|||
|
|||
Puedes escribir mensajes en el cuadro de entrada y enviarlos: |
|||
|
|||
<img src="/img/tutorial/websockets/image02.png"> |
|||
|
|||
Y tu aplicación **FastAPI** con WebSockets responderá de vuelta: |
|||
|
|||
<img src="/img/tutorial/websockets/image03.png"> |
|||
|
|||
Puedes enviar (y recibir) muchos mensajes: |
|||
|
|||
<img src="/img/tutorial/websockets/image04.png"> |
|||
|
|||
Y todos usarán la misma conexión WebSocket. |
|||
|
|||
## Usando `Depends` y otros |
|||
|
|||
En endpoints de WebSocket puedes importar desde `fastapi` y usar: |
|||
|
|||
* `Depends` |
|||
* `Security` |
|||
* `Cookie` |
|||
* `Header` |
|||
* `Path` |
|||
* `Query` |
|||
|
|||
Funcionan de la misma manera que para otros endpoints de FastAPI/*path operations*: |
|||
|
|||
{* ../../docs_src/websockets/tutorial002_an_py310.py hl[68:69,82] *} |
|||
|
|||
/// info | Información |
|||
|
|||
Como esto es un WebSocket no tiene mucho sentido lanzar un `HTTPException`, en su lugar lanzamos un `WebSocketException`. |
|||
|
|||
Puedes usar un código de cierre de los <a href="https://tools.ietf.org/html/rfc6455#section-7.4.1" class="external-link" target="_blank">códigos válidos definidos en la especificación</a>. |
|||
|
|||
/// |
|||
|
|||
### Prueba los WebSockets con dependencias |
|||
|
|||
Si tu archivo se llama `main.py`, ejecuta tu aplicación con: |
|||
|
|||
<div class="termy"> |
|||
|
|||
```console |
|||
$ fastapi dev main.py |
|||
|
|||
<span style="color: green;">INFO</span>: Uvicorn running on http://127.0.0.1:8000 (Press CTRL+C to quit) |
|||
``` |
|||
|
|||
</div> |
|||
|
|||
Abre tu navegador en <a href="http://127.0.0.1:8000" class="external-link" target="_blank">http://127.0.0.1:8000</a>. |
|||
|
|||
Ahí puedes establecer: |
|||
|
|||
* El "ID del Ítem", usado en el path. |
|||
* El "Token" usado como un parámetro query. |
|||
|
|||
/// tip | Consejo |
|||
|
|||
Nota que el query `token` será manejado por una dependencia. |
|||
|
|||
/// |
|||
|
|||
Con eso puedes conectar el WebSocket y luego enviar y recibir mensajes: |
|||
|
|||
<img src="/img/tutorial/websockets/image05.png"> |
|||
|
|||
## Manejar desconexiones y múltiples clientes |
|||
|
|||
Cuando una conexión de WebSocket se cierra, el `await websocket.receive_text()` lanzará una excepción `WebSocketDisconnect`, que puedes capturar y manejar como en este ejemplo. |
|||
|
|||
{* ../../docs_src/websockets/tutorial003_py39.py hl[79:81] *} |
|||
|
|||
Para probarlo: |
|||
|
|||
* Abre la aplicación con varias pestañas del navegador. |
|||
* Escribe mensajes desde ellas. |
|||
* Luego cierra una de las pestañas. |
|||
|
|||
Eso lanzará la excepción `WebSocketDisconnect`, y todos los otros clientes recibirán un mensaje como: |
|||
|
|||
``` |
|||
Client #1596980209979 left the chat |
|||
``` |
|||
|
|||
/// tip | Consejo |
|||
|
|||
La aplicación anterior es un ejemplo mínimo y simple para demostrar cómo manejar y transmitir mensajes a varias conexiones WebSocket. |
|||
|
|||
Pero ten en cuenta que, como todo se maneja en memoria, en una sola lista, solo funcionará mientras el proceso esté en ejecución, y solo funcionará con un solo proceso. |
|||
|
|||
Si necesitas algo fácil de integrar con FastAPI pero que sea más robusto, soportado por Redis, PostgreSQL u otros, revisa <a href="https://github.com/encode/broadcaster" class="external-link" target="_blank">encode/broadcaster</a>. |
|||
|
|||
/// |
|||
|
|||
## Más información |
|||
|
|||
Para aprender más sobre las opciones, revisa la documentación de Starlette para: |
|||
|
|||
* <a href="https://www.starlette.io/websockets/" class="external-link" target="_blank">La clase `WebSocket`</a>. |
|||
* <a href="https://www.starlette.io/endpoints/#websocketendpoint" class="external-link" target="_blank">Manejo de WebSocket basado en clases</a>. |
@ -0,0 +1,35 @@ |
|||
# Incluyendo WSGI - Flask, Django, otros |
|||
|
|||
Puedes montar aplicaciones WSGI como viste con [Sub Aplicaciones - Mounts](sub-applications.md){.internal-link target=_blank}, [Detrás de un Proxy](behind-a-proxy.md){.internal-link target=_blank}. |
|||
|
|||
Para eso, puedes usar `WSGIMiddleware` y usarlo para envolver tu aplicación WSGI, por ejemplo, Flask, Django, etc. |
|||
|
|||
## Usando `WSGIMiddleware` |
|||
|
|||
Necesitas importar `WSGIMiddleware`. |
|||
|
|||
Luego envuelve la aplicación WSGI (p. ej., Flask) con el middleware. |
|||
|
|||
Y luego móntala bajo un path. |
|||
|
|||
{* ../../docs_src/wsgi/tutorial001.py hl[2:3,3] *} |
|||
|
|||
## Revisa |
|||
|
|||
Ahora, cada request bajo el path `/v1/` será manejado por la aplicación Flask. |
|||
|
|||
Y el resto será manejado por **FastAPI**. |
|||
|
|||
Si lo ejecutas y vas a <a href="http://localhost:8000/v1/" class="external-link" target="_blank">http://localhost:8000/v1/</a> verás el response de Flask: |
|||
|
|||
```txt |
|||
Hello, World from Flask! |
|||
``` |
|||
|
|||
Y si vas a <a href="http://localhost:8000/v2" class="external-link" target="_blank">http://localhost:8000/v2</a> verás el response de FastAPI: |
|||
|
|||
```JSON |
|||
{ |
|||
"message": "Hello World" |
|||
} |
|||
``` |
@ -0,0 +1,485 @@ |
|||
# Alternativas, Inspiración y Comparaciones |
|||
|
|||
Lo que inspiró a **FastAPI**, cómo se compara con las alternativas y lo que aprendió de ellas. |
|||
|
|||
## Introducción |
|||
|
|||
**FastAPI** no existiría si no fuera por el trabajo previo de otros. |
|||
|
|||
Se han creado muchas herramientas antes que han ayudado a inspirar su creación. |
|||
|
|||
He estado evitando la creación de un nuevo framework durante varios años. Primero intenté resolver todas las funcionalidades cubiertas por **FastAPI** usando muchos frameworks diferentes, plug-ins y herramientas. |
|||
|
|||
Pero en algún punto, no hubo otra opción que crear algo que proporcionara todas estas funcionalidades, tomando las mejores ideas de herramientas previas y combinándolas de la mejor manera posible, usando funcionalidades del lenguaje que ni siquiera estaban disponibles antes (anotaciones de tipos de Python 3.6+). |
|||
|
|||
## Herramientas previas |
|||
|
|||
### <a href="https://www.djangoproject.com/" class="external-link" target="_blank">Django</a> |
|||
|
|||
Es el framework más popular de Python y es ampliamente confiable. Se utiliza para construir sistemas como Instagram. |
|||
|
|||
Está relativamente acoplado con bases de datos relacionales (como MySQL o PostgreSQL), por lo que tener una base de datos NoSQL (como Couchbase, MongoDB, Cassandra, etc) como motor de almacenamiento principal no es muy fácil. |
|||
|
|||
Fue creado para generar el HTML en el backend, no para crear APIs utilizadas por un frontend moderno (como React, Vue.js y Angular) o por otros sistemas (como dispositivos del <abbr title="Internet of Things">IoT</abbr>) comunicándose con él. |
|||
|
|||
### <a href="https://www.django-rest-framework.org/" class="external-link" target="_blank">Django REST Framework</a> |
|||
|
|||
El framework Django REST fue creado para ser un kit de herramientas flexible para construir APIs Web utilizando Django, mejorando sus capacidades API. |
|||
|
|||
Es utilizado por muchas empresas, incluidas Mozilla, Red Hat y Eventbrite. |
|||
|
|||
Fue uno de los primeros ejemplos de **documentación automática de APIs**, y esto fue específicamente una de las primeras ideas que inspiraron "la búsqueda de" **FastAPI**. |
|||
|
|||
/// note | Nota |
|||
|
|||
Django REST Framework fue creado por Tom Christie. El mismo creador de Starlette y Uvicorn, en los cuales **FastAPI** está basado. |
|||
|
|||
/// |
|||
|
|||
/// check | Inspiró a **FastAPI** a |
|||
|
|||
Tener una interfaz de usuario web de documentación automática de APIs. |
|||
|
|||
/// |
|||
|
|||
### <a href="https://flask.palletsprojects.com" class="external-link" target="_blank">Flask</a> |
|||
|
|||
Flask es un "microframework", no incluye integraciones de bases de datos ni muchas de las cosas que vienen por defecto en Django. |
|||
|
|||
Esta simplicidad y flexibilidad permiten hacer cosas como usar bases de datos NoSQL como el sistema de almacenamiento de datos principal. |
|||
|
|||
Como es muy simple, es relativamente intuitivo de aprender, aunque la documentación se vuelve algo técnica en algunos puntos. |
|||
|
|||
También se utiliza comúnmente para otras aplicaciones que no necesariamente necesitan una base de datos, gestión de usuarios, o cualquiera de las muchas funcionalidades que vienen preconstruidas en Django. Aunque muchas de estas funcionalidades se pueden añadir con plug-ins. |
|||
|
|||
Esta separación de partes, y ser un "microframework" que podría extenderse para cubrir exactamente lo que se necesita, fue una funcionalidad clave que quise mantener. |
|||
|
|||
Dada la simplicidad de Flask, parecía una buena opción para construir APIs. Lo siguiente a encontrar era un "Django REST Framework" para Flask. |
|||
|
|||
/// check | Inspiró a **FastAPI** a |
|||
|
|||
Ser un micro-framework. Haciendo fácil mezclar y combinar las herramientas y partes necesarias. |
|||
|
|||
Tener un sistema de routing simple y fácil de usar. |
|||
|
|||
/// |
|||
|
|||
### <a href="https://requests.readthedocs.io" class="external-link" target="_blank">Requests</a> |
|||
|
|||
**FastAPI** no es en realidad una alternativa a **Requests**. Su ámbito es muy diferente. |
|||
|
|||
De hecho, sería común usar Requests *dentro* de una aplicación FastAPI. |
|||
|
|||
Aun así, FastAPI se inspiró bastante en Requests. |
|||
|
|||
**Requests** es un paquete para *interactuar* con APIs (como cliente), mientras que **FastAPI** es un paquete para *construir* APIs (como servidor). |
|||
|
|||
Están, más o menos, en extremos opuestos, complementándose entre sí. |
|||
|
|||
Requests tiene un diseño muy simple e intuitivo, es muy fácil de usar, con valores predeterminados sensatos. Pero al mismo tiempo, es muy poderoso y personalizable. |
|||
|
|||
Por eso, como se dice en el sitio web oficial: |
|||
|
|||
> Requests es uno de los paquetes Python más descargados de todos los tiempos |
|||
|
|||
La forma en que lo usas es muy sencilla. Por ejemplo, para hacer un `GET` request, escribirías: |
|||
|
|||
```Python |
|||
response = requests.get("http://example.com/some/url") |
|||
``` |
|||
|
|||
La operación de path equivalente en FastAPI podría verse como: |
|||
|
|||
```Python hl_lines="1" |
|||
@app.get("/some/url") |
|||
def read_url(): |
|||
return {"message": "Hello World"} |
|||
``` |
|||
|
|||
Mira las similitudes entre `requests.get(...)` y `@app.get(...)`. |
|||
|
|||
/// check | Inspiró a **FastAPI** a |
|||
|
|||
* Tener un API simple e intuitivo. |
|||
* Usar nombres de métodos HTTP (operaciones) directamente, de una manera sencilla e intuitiva. |
|||
* Tener valores predeterminados sensatos, pero personalizaciones poderosas. |
|||
|
|||
/// |
|||
|
|||
### <a href="https://swagger.io/" class="external-link" target="_blank">Swagger</a> / <a href="https://github.com/OAI/OpenAPI-Specification/" class="external-link" target="_blank">OpenAPI</a> |
|||
|
|||
La principal funcionalidad que quería de Django REST Framework era la documentación automática de la API. |
|||
|
|||
Luego descubrí que había un estándar para documentar APIs, usando JSON (o YAML, una extensión de JSON) llamado Swagger. |
|||
|
|||
Y ya existía una interfaz de usuario web para las APIs Swagger. Por lo tanto, ser capaz de generar documentación Swagger para una API permitiría usar esta interfaz de usuario web automáticamente. |
|||
|
|||
En algún punto, Swagger fue entregado a la Linux Foundation, para ser renombrado OpenAPI. |
|||
|
|||
Es por eso que cuando se habla de la versión 2.0 es común decir "Swagger", y para la versión 3+ "OpenAPI". |
|||
|
|||
/// check | Inspiró a **FastAPI** a |
|||
|
|||
Adoptar y usar un estándar abierto para especificaciones de API, en lugar de usar un esquema personalizado. |
|||
|
|||
Y a integrar herramientas de interfaz de usuario basadas en estándares: |
|||
|
|||
* <a href="https://github.com/swagger-api/swagger-ui" class="external-link" target="_blank">Swagger UI</a> |
|||
* <a href="https://github.com/Rebilly/ReDoc" class="external-link" target="_blank">ReDoc</a> |
|||
|
|||
Estas dos fueron elegidas por ser bastante populares y estables, pero haciendo una búsqueda rápida, podrías encontrar docenas de interfaces de usuario alternativas para OpenAPI (que puedes usar con **FastAPI**). |
|||
|
|||
/// |
|||
|
|||
### Frameworks REST para Flask |
|||
|
|||
Existen varios frameworks REST para Flask, pero después de invertir tiempo y trabajo investigándolos, encontré que muchos son descontinuados o abandonados, con varios problemas existentes que los hacían inadecuados. |
|||
|
|||
### <a href="https://marshmallow.readthedocs.io/en/stable/" class="external-link" target="_blank">Marshmallow</a> |
|||
|
|||
Una de las principales funcionalidades necesitadas por los sistemas API es la "<abbr title="también llamada marshalling, conversión">serialización</abbr>" de datos, que consiste en tomar datos del código (Python) y convertirlos en algo que pueda ser enviado a través de la red. Por ejemplo, convertir un objeto que contiene datos de una base de datos en un objeto JSON. Convertir objetos `datetime` en strings, etc. |
|||
|
|||
Otra gran funcionalidad necesaria por las APIs es la validación de datos, asegurarse de que los datos sean válidos, dados ciertos parámetros. Por ejemplo, que algún campo sea un `int`, y no algún string aleatorio. Esto es especialmente útil para los datos entrantes. |
|||
|
|||
Sin un sistema de validación de datos, tendrías que hacer todas las comprobaciones a mano, en código. |
|||
|
|||
Estas funcionalidades son para lo que fue creado Marshmallow. Es un gran paquete, y lo he usado mucho antes. |
|||
|
|||
Pero fue creado antes de que existieran las anotaciones de tipos en Python. Así que, para definir cada <abbr title="la definición de cómo deberían formarse los datos">esquema</abbr> necesitas usar utilidades y clases específicas proporcionadas por Marshmallow. |
|||
|
|||
/// check | Inspiró a **FastAPI** a |
|||
|
|||
Usar código para definir "esquemas" que proporcionen tipos de datos y validación automáticamente. |
|||
|
|||
/// |
|||
|
|||
### <a href="https://webargs.readthedocs.io/en/latest/" class="external-link" target="_blank">Webargs</a> |
|||
|
|||
Otra gran funcionalidad requerida por las APIs es el <abbr title="lectura y conversión a datos de Python">parse</abbr> de datos de las requests entrantes. |
|||
|
|||
Webargs es una herramienta que fue creada para proporcionar esa funcionalidad sobre varios frameworks, incluido Flask. |
|||
|
|||
Usa Marshmallow por debajo para hacer la validación de datos. Y fue creada por los mismos desarrolladores. |
|||
|
|||
Es una gran herramienta y la he usado mucho también, antes de tener **FastAPI**. |
|||
|
|||
/// info | Información |
|||
|
|||
Webargs fue creada por los mismos desarrolladores de Marshmallow. |
|||
|
|||
/// |
|||
|
|||
/// check | Inspiró a **FastAPI** a |
|||
|
|||
Tener validación automática de datos entrantes en una request. |
|||
|
|||
/// |
|||
|
|||
### <a href="https://apispec.readthedocs.io/en/stable/" class="external-link" target="_blank">APISpec</a> |
|||
|
|||
Marshmallow y Webargs proporcionan validación, parse y serialización como plug-ins. |
|||
|
|||
Pero la documentación todavía falta. Entonces APISpec fue creado. |
|||
|
|||
Es un plug-in para muchos frameworks (y hay un plug-in para Starlette también). |
|||
|
|||
La manera en que funciona es que escribes la definición del esquema usando el formato YAML dentro del docstring de cada función que maneja una ruta. |
|||
|
|||
Y genera esquemas OpenAPI. |
|||
|
|||
Así es como funciona en Flask, Starlette, Responder, etc. |
|||
|
|||
Pero luego, tenemos otra vez el problema de tener una micro-sintaxis, dentro de un string de Python (un gran YAML). |
|||
|
|||
El editor no puede ayudar mucho con eso. Y si modificamos parámetros o esquemas de Marshmallow y olvidamos también modificar ese docstring YAML, el esquema generado estaría obsoleto. |
|||
|
|||
/// info | Información |
|||
|
|||
APISpec fue creado por los mismos desarrolladores de Marshmallow. |
|||
|
|||
/// |
|||
|
|||
/// check | Inspiró a **FastAPI** a |
|||
|
|||
Soportar el estándar abierto para APIs, OpenAPI. |
|||
|
|||
/// |
|||
|
|||
### <a href="https://flask-apispec.readthedocs.io/en/latest/" class="external-link" target="_blank">Flask-apispec</a> |
|||
|
|||
Es un plug-in de Flask, que conecta juntos Webargs, Marshmallow y APISpec. |
|||
|
|||
Usa la información de Webargs y Marshmallow para generar automáticamente esquemas OpenAPI, usando APISpec. |
|||
|
|||
Es una gran herramienta, muy subestimada. Debería ser mucho más popular que muchos plug-ins de Flask por ahí. Puede que se deba a que su documentación es demasiado concisa y abstracta. |
|||
|
|||
Esto resolvió tener que escribir YAML (otra sintaxis) dentro de docstrings de Python. |
|||
|
|||
Esta combinación de Flask, Flask-apispec con Marshmallow y Webargs fue mi stack de backend favorito hasta construir **FastAPI**. |
|||
|
|||
Usarlo llevó a la creación de varios generadores de full-stack para Flask. Estos son los principales stacks que yo (y varios equipos externos) hemos estado usando hasta ahora: |
|||
|
|||
* <a href="https://github.com/tiangolo/full-stack" class="external-link" target="_blank">https://github.com/tiangolo/full-stack</a> |
|||
* <a href="https://github.com/tiangolo/full-stack-flask-couchbase" class="external-link" target="_blank">https://github.com/tiangolo/full-stack-flask-couchbase</a> |
|||
* <a href="https://github.com/tiangolo/full-stack-flask-couchdb" class="external-link" target="_blank">https://github.com/tiangolo/full-stack-flask-couchdb</a> |
|||
|
|||
Y estos mismos generadores de full-stack fueron la base de los [Generadores de Proyectos **FastAPI**](project-generation.md){.internal-link target=_blank}. |
|||
|
|||
/// info | Información |
|||
|
|||
Flask-apispec fue creado por los mismos desarrolladores de Marshmallow. |
|||
|
|||
/// |
|||
|
|||
/// check | Inspiró a **FastAPI** a |
|||
|
|||
Generar el esquema OpenAPI automáticamente, desde el mismo código que define la serialización y validación. |
|||
|
|||
/// |
|||
|
|||
### <a href="https://nestjs.com/" class="external-link" target="_blank">NestJS</a> (y <a href="https://angular.io/" class="external-link" target="_blank">Angular</a>) |
|||
|
|||
Esto ni siquiera es Python, NestJS es un framework de JavaScript (TypeScript) NodeJS inspirado por Angular. |
|||
|
|||
Logra algo algo similar a lo que se puede hacer con Flask-apispec. |
|||
|
|||
Tiene un sistema de inyección de dependencias integrado, inspirado por Angular 2. Requiere pre-registrar los "inyectables" (como todos los otros sistemas de inyección de dependencias que conozco), por lo que añade a la verbosidad y repetición de código. |
|||
|
|||
Como los parámetros se describen con tipos de TypeScript (similar a las anotaciones de tipos en Python), el soporte editorial es bastante bueno. |
|||
|
|||
Pero como los datos de TypeScript no se preservan después de la compilación a JavaScript, no puede depender de los tipos para definir validación, serialización y documentación al mismo tiempo. Debido a esto y algunas decisiones de diseño, para obtener validación, serialización y generación automática del esquema, es necesario agregar decoradores en muchos lugares. Por lo tanto, se vuelve bastante verboso. |
|||
|
|||
No puede manejar muy bien modelos anidados. Entonces, si el cuerpo JSON en la request es un objeto JSON que tiene campos internos que a su vez son objetos JSON anidados, no puede ser documentado y validado apropiadamente. |
|||
|
|||
/// check | Inspiró a **FastAPI** a |
|||
|
|||
Usar tipos de Python para tener un gran soporte del editor. |
|||
|
|||
Tener un poderoso sistema de inyección de dependencias. Encontrar una forma de minimizar la repetición de código. |
|||
|
|||
/// |
|||
|
|||
### <a href="https://sanic.readthedocs.io/en/latest/" class="external-link" target="_blank">Sanic</a> |
|||
|
|||
Fue uno de los primeros frameworks de Python extremadamente rápidos basados en `asyncio`. Fue hecho para ser muy similar a Flask. |
|||
|
|||
/// note | Detalles Técnicos |
|||
|
|||
Usó <a href="https://github.com/MagicStack/uvloop" class="external-link" target="_blank">`uvloop`</a> en lugar del loop `asyncio` por defecto de Python. Eso fue lo que lo hizo tan rápido. |
|||
|
|||
Claramente inspiró a Uvicorn y Starlette, que actualmente son más rápidos que Sanic en benchmarks abiertos. |
|||
|
|||
/// |
|||
|
|||
/// check | Inspiró a **FastAPI** a |
|||
|
|||
Encontrar una manera de tener un rendimiento impresionante. |
|||
|
|||
Por eso **FastAPI** se basa en Starlette, ya que es el framework más rápido disponible (probado por benchmarks de terceros). |
|||
|
|||
/// |
|||
|
|||
### <a href="https://falconframework.org/" class="external-link" target="_blank">Falcon</a> |
|||
|
|||
Falcon es otro framework de Python de alto rendimiento, está diseñado para ser minimalista y funcionar como la base de otros frameworks como Hug. |
|||
|
|||
Está diseñado para tener funciones que reciben dos parámetros, un "request" y un "response". Luego "lees" partes del request y "escribes" partes en el response. Debido a este diseño, no es posible declarar parámetros de request y cuerpos con las anotaciones de tipos estándar de Python como parámetros de función. |
|||
|
|||
Por lo tanto, la validación de datos, la serialización y la documentación, tienen que hacerse en código, no automáticamente. O tienen que implementarse como un framework sobre Falcon, como Hug. Esta misma distinción ocurre en otros frameworks que se inspiran en el diseño de Falcon, de tener un objeto request y un objeto response como parámetros. |
|||
|
|||
/// check | Inspiró a **FastAPI** a |
|||
|
|||
Buscar maneras de obtener un gran rendimiento. |
|||
|
|||
Junto con Hug (ya que Hug se basa en Falcon), inspiraron a **FastAPI** a declarar un parámetro `response` en las funciones. |
|||
|
|||
Aunque en FastAPI es opcional, y se utiliza principalmente para configurar headers, cookies y códigos de estado alternativos. |
|||
|
|||
/// |
|||
|
|||
### <a href="https://moltenframework.com/" class="external-link" target="_blank">Molten</a> |
|||
|
|||
Descubrí Molten en las primeras etapas de construcción de **FastAPI**. Y tiene ideas bastante similares: |
|||
|
|||
* Basado en las anotaciones de tipos de Python. |
|||
* Validación y documentación a partir de estos tipos. |
|||
* Sistema de Inyección de Dependencias. |
|||
|
|||
No utiliza un paquete de validación de datos, serialización y documentación de terceros como Pydantic, tiene el suyo propio. Por lo tanto, estas definiciones de tipos de datos no serían reutilizables tan fácilmente. |
|||
|
|||
Requiere configuraciones un poquito más verbosas. Y dado que se basa en WSGI (en lugar de ASGI), no está diseñado para aprovechar el alto rendimiento proporcionado por herramientas como Uvicorn, Starlette y Sanic. |
|||
|
|||
El sistema de inyección de dependencias requiere pre-registrar las dependencias y las dependencias se resuelven en base a los tipos declarados. Por lo tanto, no es posible declarar más de un "componente" que proporcione cierto tipo. |
|||
|
|||
Las rutas se declaran en un solo lugar, usando funciones declaradas en otros lugares (en lugar de usar decoradores que pueden colocarse justo encima de la función que maneja el endpoint). Esto se acerca más a cómo lo hace Django que a cómo lo hace Flask (y Starlette). Separa en el código cosas que están relativamente acopladas. |
|||
|
|||
/// check | Inspiró a **FastAPI** a |
|||
|
|||
Definir validaciones extra para tipos de datos usando el valor "default" de los atributos del modelo. Esto mejora el soporte del editor y no estaba disponible en Pydantic antes. |
|||
|
|||
Esto en realidad inspiró la actualización de partes de Pydantic, para soportar el mismo estilo de declaración de validación (toda esta funcionalidad ya está disponible en Pydantic). |
|||
|
|||
/// |
|||
|
|||
### <a href="https://github.com/hugapi/hug" class="external-link" target="_blank">Hug</a> |
|||
|
|||
Hug fue uno de los primeros frameworks en implementar la declaración de tipos de parámetros API usando las anotaciones de tipos de Python. Esta fue una gran idea que inspiró a otras herramientas a hacer lo mismo. |
|||
|
|||
Usaba tipos personalizados en sus declaraciones en lugar de tipos estándar de Python, pero aún así fue un gran avance. |
|||
|
|||
También fue uno de los primeros frameworks en generar un esquema personalizado declarando toda la API en JSON. |
|||
|
|||
No se basaba en un estándar como OpenAPI y JSON Schema. Por lo que no sería sencillo integrarlo con otras herramientas, como Swagger UI. Pero, nuevamente, fue una idea muy innovadora. |
|||
|
|||
Tiene una funcionalidad interesante e inusual: usando el mismo framework, es posible crear APIs y también CLIs. |
|||
|
|||
Dado que se basa en el estándar previo para frameworks web Python sincrónicos (WSGI), no puede manejar Websockets y otras cosas, aunque aún así tiene un alto rendimiento también. |
|||
|
|||
/// info | Información |
|||
|
|||
Hug fue creado por Timothy Crosley, el mismo creador de <a href="https://github.com/timothycrosley/isort" class="external-link" target="_blank">`isort`</a>, una gran herramienta para ordenar automáticamente imports en archivos Python. |
|||
|
|||
/// |
|||
|
|||
/// check | Ideas que inspiraron a **FastAPI** |
|||
|
|||
Hug inspiró partes de APIStar, y fue una de las herramientas que encontré más prometedoras, junto a APIStar. |
|||
|
|||
Hug ayudó a inspirar a **FastAPI** a usar anotaciones de tipos de Python para declarar parámetros, y a generar un esquema definiendo la API automáticamente. |
|||
|
|||
Hug inspiró a **FastAPI** a declarar un parámetro `response` en funciones para configurar headers y cookies. |
|||
|
|||
/// |
|||
|
|||
### <a href="https://github.com/encode/apistar" class="external-link" target="_blank">APIStar</a> (<= 0.5) |
|||
|
|||
Justo antes de decidir construir **FastAPI** encontré **APIStar** server. Tenía casi todo lo que estaba buscando y tenía un gran diseño. |
|||
|
|||
Era una de las primeras implementaciones de un framework utilizando las anotaciones de tipos de Python para declarar parámetros y requests que jamás vi (antes de NestJS y Molten). Lo encontré más o menos al mismo tiempo que Hug. Pero APIStar usaba el estándar OpenAPI. |
|||
|
|||
Tenía validación de datos automática, serialización de datos y generación del esquema OpenAPI basada en las mismas anotaciones de tipos en varios lugares. |
|||
|
|||
Las definiciones de esquema de cuerpo no usaban las mismas anotaciones de tipos de Python como Pydantic, era un poco más similar a Marshmallow, por lo que el soporte del editor no sería tan bueno, pero aún así, APIStar era la mejor opción disponible. |
|||
|
|||
Tenía los mejores benchmarks de rendimiento en ese momento (solo superado por Starlette). |
|||
|
|||
Al principio, no tenía una interfaz de usuario web de documentación de API automática, pero sabía que podía agregar Swagger UI a él. |
|||
|
|||
Tenía un sistema de inyección de dependencias. Requería pre-registrar componentes, como otras herramientas discutidas anteriormente. Pero aún así, era una gran funcionalidad. |
|||
|
|||
Nunca pude usarlo en un proyecto completo, ya que no tenía integración de seguridad, por lo que no podía reemplazar todas las funcionalidades que tenía con los generadores de full-stack basados en Flask-apispec. Tenía en mi lista de tareas pendientes de proyectos crear un pull request agregando esa funcionalidad. |
|||
|
|||
Pero luego, el enfoque del proyecto cambió. |
|||
|
|||
Ya no era un framework web API, ya que el creador necesitaba enfocarse en Starlette. |
|||
|
|||
Ahora APIStar es un conjunto de herramientas para validar especificaciones OpenAPI, no un framework web. |
|||
|
|||
/// info | Información |
|||
|
|||
APIStar fue creado por Tom Christie. El mismo que creó: |
|||
|
|||
* Django REST Framework |
|||
* Starlette (en la cual **FastAPI** está basado) |
|||
* Uvicorn (usado por Starlette y **FastAPI**) |
|||
|
|||
/// |
|||
|
|||
/// check | Inspiró a **FastAPI** a |
|||
|
|||
Existir. |
|||
|
|||
La idea de declarar múltiples cosas (validación de datos, serialización y documentación) con los mismos tipos de Python, que al mismo tiempo proporcionaban un gran soporte del editor, era algo que consideré una idea brillante. |
|||
|
|||
Y después de buscar durante mucho tiempo un framework similar y probar muchas alternativas diferentes, APIStar fue la mejor opción disponible. |
|||
|
|||
Luego APIStar dejó de existir como servidor y Starlette fue creado, y fue una nueva y mejor base para tal sistema. Esa fue la inspiración final para construir **FastAPI**. |
|||
|
|||
Considero a **FastAPI** un "sucesor espiritual" de APIStar, mientras mejora y aumenta las funcionalidades, el sistema de tipos y otras partes, basándose en los aprendizajes de todas estas herramientas previas. |
|||
|
|||
/// |
|||
|
|||
## Usado por **FastAPI** |
|||
|
|||
### <a href="https://docs.pydantic.dev/" class="external-link" target="_blank">Pydantic</a> |
|||
|
|||
Pydantic es un paquete para definir validación de datos, serialización y documentación (usando JSON Schema) basándose en las anotaciones de tipos de Python. |
|||
|
|||
Eso lo hace extremadamente intuitivo. |
|||
|
|||
Es comparable a Marshmallow. Aunque es más rápido que Marshmallow en benchmarks. Y como está basado en las mismas anotaciones de tipos de Python, el soporte del editor es estupendo. |
|||
|
|||
/// check | **FastAPI** lo usa para |
|||
|
|||
Manejar toda la validación de datos, serialización de datos y documentación automática de modelos (basada en JSON Schema). |
|||
|
|||
**FastAPI** luego toma esos datos JSON Schema y los coloca en OpenAPI, aparte de todas las otras cosas que hace. |
|||
|
|||
/// |
|||
|
|||
### <a href="https://www.starlette.io/" class="external-link" target="_blank">Starlette</a> |
|||
|
|||
Starlette es un framework/toolkit <abbr title="El nuevo estándar para construir aplicaciones web asíncronas en Python">ASGI</abbr> liviano, ideal para construir servicios asyncio de alto rendimiento. |
|||
|
|||
Es muy simple e intuitivo. Está diseñado para ser fácilmente extensible y tener componentes modulares. |
|||
|
|||
Tiene: |
|||
|
|||
* Un rendimiento seriamente impresionante. |
|||
* Soporte para WebSocket. |
|||
* Tareas en segundo plano dentro del proceso. |
|||
* Eventos de inicio y apagado. |
|||
* Cliente de pruebas basado en HTTPX. |
|||
* CORS, GZip, Archivos estáticos, Responses en streaming. |
|||
* Soporte para sesiones y cookies. |
|||
* Cobertura de tests del 100%. |
|||
* Base de código 100% tipada. |
|||
* Pocas dependencias obligatorias. |
|||
|
|||
Starlette es actualmente el framework de Python más rápido probado. Solo superado por Uvicorn, que no es un framework, sino un servidor. |
|||
|
|||
Starlette proporciona toda la funcionalidad básica de un microframework web. |
|||
|
|||
Pero no proporciona validación de datos automática, serialización o documentación. |
|||
|
|||
Esa es una de las principales cosas que **FastAPI** agrega, todo basado en las anotaciones de tipos de Python (usando Pydantic). Eso, además del sistema de inyección de dependencias, utilidades de seguridad, generación de esquemas OpenAPI, etc. |
|||
|
|||
/// note | Detalles Técnicos |
|||
|
|||
ASGI es un nuevo "estándar" que está siendo desarrollado por miembros del equipo central de Django. Todavía no es un "estándar de Python" (un PEP), aunque están en proceso de hacerlo. |
|||
|
|||
No obstante, ya está siendo usado como un "estándar" por varias herramientas. Esto mejora enormemente la interoperabilidad, ya que podrías cambiar Uvicorn por cualquier otro servidor ASGI (como Daphne o Hypercorn), o podrías añadir herramientas compatibles con ASGI, como `python-socketio`. |
|||
|
|||
/// |
|||
|
|||
/// check | **FastAPI** lo usa para |
|||
|
|||
Manejar todas las partes web centrales. Añadiendo funcionalidades encima. |
|||
|
|||
La clase `FastAPI` en sí misma hereda directamente de la clase `Starlette`. |
|||
|
|||
Por lo tanto, cualquier cosa que puedas hacer con Starlette, puedes hacerlo directamente con **FastAPI**, ya que es básicamente Starlette potenciado. |
|||
|
|||
/// |
|||
|
|||
### <a href="https://www.uvicorn.org/" class="external-link" target="_blank">Uvicorn</a> |
|||
|
|||
Uvicorn es un servidor ASGI extremadamente rápido, construido sobre uvloop y httptools. |
|||
|
|||
No es un framework web, sino un servidor. Por ejemplo, no proporciona herramientas para el enrutamiento por paths. Eso es algo que un framework como Starlette (o **FastAPI**) proporcionaría encima. |
|||
|
|||
Es el servidor recomendado para Starlette y **FastAPI**. |
|||
|
|||
/// check | **FastAPI** lo recomienda como |
|||
|
|||
El servidor web principal para ejecutar aplicaciones **FastAPI**. |
|||
|
|||
También puedes usar la opción de línea de comandos `--workers` para tener un servidor multiproceso asíncrono. |
|||
|
|||
Revisa más detalles en la sección [Despliegue](deployment/index.md){.internal-link target=_blank}. |
|||
|
|||
/// |
|||
|
|||
## Benchmarks y velocidad |
|||
|
|||
Para entender, comparar, y ver la diferencia entre Uvicorn, Starlette y FastAPI, revisa la sección sobre [Benchmarks](benchmarks.md){.internal-link target=_blank}. |
@ -1,33 +1,34 @@ |
|||
# Benchmarks |
|||
|
|||
Los benchmarks independientes de TechEmpower muestran aplicaciones de **FastAPI** que se ejecutan en Uvicorn como <a href="https://www.techempower.com/benchmarks/#section=test&runid=7464e520-0dc2-473d-bd34-dbdfd7e85911&hw=ph&test=query&l= zijzen-7" class="external-link" target="_blank">uno de los frameworks de Python más rápidos disponibles</a>, solo por debajo de Starlette y Uvicorn (utilizados internamente por FastAPI). (*) |
|||
Los benchmarks independientes de TechEmpower muestran aplicaciones de **FastAPI** ejecutándose bajo Uvicorn como <a href="https://www.techempower.com/benchmarks/#section=test&runid=7464e520-0dc2-473d-bd34-dbdfd7e85911&hw=ph&test=query&l=zijzen-7" class="external-link" target="_blank">uno de los frameworks de Python más rápidos disponibles</a>, solo por debajo de Starlette y Uvicorn en sí mismos (utilizados internamente por FastAPI). |
|||
|
|||
Pero al comprobar benchmarks y comparaciones debes tener en cuenta lo siguiente. |
|||
Pero al revisar benchmarks y comparaciones, debes tener en cuenta lo siguiente. |
|||
|
|||
## Benchmarks y velocidad |
|||
|
|||
Cuando revisas los benchmarks, es común ver varias herramientas de diferentes tipos comparadas como equivalentes. |
|||
Cuando ves los benchmarks, es común ver varias herramientas de diferentes tipos comparadas como equivalentes. |
|||
|
|||
Específicamente, para ver Uvicorn, Starlette y FastAPI comparadas entre sí (entre muchas otras herramientas). |
|||
Específicamente, ver Uvicorn, Starlette y FastAPI comparados juntos (entre muchas otras herramientas). |
|||
|
|||
Cuanto más sencillo sea el problema resuelto por la herramienta, mejor rendimiento obtendrá. Y la mayoría de los benchmarks no prueban las funciones adicionales proporcionadas por la herramienta. |
|||
Cuanto más simple sea el problema resuelto por la herramienta, mejor rendimiento tendrá. Y la mayoría de los benchmarks no prueban las funcionalidades adicionales proporcionadas por la herramienta. |
|||
|
|||
La jerarquía sería: |
|||
La jerarquía es como: |
|||
|
|||
* **Uvicorn**: como servidor ASGI |
|||
* **Uvicorn**: un servidor ASGI |
|||
* **Starlette**: (usa Uvicorn) un microframework web |
|||
* **FastAPI**: (usa Starlette) un microframework API con varias características adicionales para construir APIs, con validación de datos, etc. |
|||
* **FastAPI**: (usa Starlette) un microframework para APIs con varias funcionalidades adicionales para construir APIs, con validación de datos, etc. |
|||
|
|||
* **Uvicorn**: |
|||
* Tendrá el mejor rendimiento, ya que no tiene mucho código extra aparte del propio servidor. |
|||
* No escribirías una aplicación directamente en Uvicorn. Eso significaría que tu código tendría que incluir más o menos, al menos, todo el código proporcionado por Starlette (o **FastAPI**). Y si hicieras eso, tu aplicación final tendría la misma sobrecarga que si hubieras usado un framework y minimizado el código de tu aplicación y los errores. |
|||
* Si estás comparando Uvicorn, compáralo con los servidores de aplicaciones Daphne, Hypercorn, uWSGI, etc. |
|||
* No escribirías una aplicación directamente en Uvicorn. Eso significaría que tu código tendría que incluir, más o menos, al menos, todo el código proporcionado por Starlette (o **FastAPI**). Y si hicieras eso, tu aplicación final tendría la misma carga que si hubieras usado un framework, minimizando el código de tu aplicación y los bugs. |
|||
* Si estás comparando Uvicorn, compáralo con Daphne, Hypercorn, uWSGI, etc. Servidores de aplicaciones. |
|||
* **Starlette**: |
|||
* Tendrá el siguiente mejor desempeño, después de Uvicorn. De hecho, Starlette usa Uvicorn para correr. Por lo tanto, probablemente sólo pueda volverse "más lento" que Uvicorn al tener que ejecutar más código. |
|||
* Pero te proporciona las herramientas para crear aplicaciones web simples, con <abbr title="también conocido en español como: enrutamiento">routing</abbr> basado en <abbr title="tambien conocido en español como: rutas">paths</abbr>, etc. |
|||
* Tendrá el siguiente mejor rendimiento, después de Uvicorn. De hecho, Starlette usa Uvicorn para ejecutarse. Así que probablemente solo pueda ser "más lento" que Uvicorn por tener que ejecutar más código. |
|||
* Pero te proporciona las herramientas para construir aplicaciones web sencillas, con enrutamiento basado en paths, etc. |
|||
* Si estás comparando Starlette, compáralo con Sanic, Flask, Django, etc. Frameworks web (o microframeworks). |
|||
* **FastAPI**: |
|||
* De la misma manera que Starlette usa Uvicorn y no puede ser más rápido que él, **FastAPI** usa Starlette, por lo que no puede ser más rápido que él. |
|||
* * FastAPI ofrece más características además de las de Starlette. Funciones que casi siempre necesitas al crear una API, como validación y serialización de datos. Y al usarlo, obtienes documentación automática de forma gratuita (la documentación automática ni siquiera agrega gastos generales a las aplicaciones en ejecución, se genera al iniciar). |
|||
* Si no usaras FastAPI y usaras Starlette directamente (u otra herramienta, como Sanic, Flask, Responder, etc.), tendrías que implementar toda la validación y serialización de datos tu mismo. Por lo tanto, tu aplicación final seguirá teniendo la misma sobrecarga que si se hubiera creado con FastAPI. Y en muchos casos, esta validación y serialización de datos constituye la mayor cantidad de código escrito en las aplicaciones. |
|||
* Entonces, al usar FastAPI estás ahorrando tiempo de desarrollo, errores, líneas de código y probablemente obtendrías el mismo rendimiento (o mejor) que obtendrías si no lo usaras (ya que tendrías que implementarlo todo en tu código). |
|||
* Si estás comparando FastAPI, compáralo con un framework de aplicaciones web (o conjunto de herramientas) que proporciona validación, serialización y documentación de datos, como Flask-apispec, NestJS, Molten, etc. Frameworks con validación, serialización y documentación automáticas integradas. |
|||
* De la misma forma en que Starlette usa Uvicorn y no puede ser más rápido que él, **FastAPI** usa Starlette, por lo que no puede ser más rápido que él. |
|||
* FastAPI ofrece más funcionalidades además de las de Starlette. Funcionalidades que casi siempre necesitas al construir APIs, como la validación y serialización de datos. Y al utilizarlo, obtienes documentación automática gratis (la documentación automática ni siquiera añade carga a las aplicaciones en ejecución, se genera al inicio). |
|||
* Si no usabas FastAPI y utilizabas Starlette directamente (u otra herramienta, como Sanic, Flask, Responder, etc.) tendrías que implementar toda la validación y serialización de datos por ti mismo. Entonces, tu aplicación final aún tendría la misma carga que si hubiera sido construida usando FastAPI. Y en muchos casos, esta validación y serialización de datos es la mayor cantidad de código escrito en las aplicaciones. |
|||
* Entonces, al usar FastAPI estás ahorrando tiempo de desarrollo, bugs, líneas de código, y probablemente obtendrías el mismo rendimiento (o mejor) que si no lo usaras (ya que tendrías que implementarlo todo en tu código). |
|||
* Si estás comparando FastAPI, compáralo con un framework de aplicación web (o conjunto de herramientas) que proporcione validación de datos, serialización y documentación, como Flask-apispec, NestJS, Molten, etc. Frameworks con validación de datos, serialización y documentación automáticas integradas. |
|||
|
@ -0,0 +1,18 @@ |
|||
# Despliega FastAPI en Proveedores de Nube |
|||
|
|||
Puedes usar prácticamente **cualquier proveedor de nube** para desplegar tu aplicación FastAPI. |
|||
|
|||
En la mayoría de los casos, los principales proveedores de nube tienen guías para desplegar FastAPI con ellos. |
|||
|
|||
## Proveedores de Nube - Sponsors |
|||
|
|||
Algunos proveedores de nube ✨ [**son sponsors de FastAPI**](../help-fastapi.md#sponsor-the-author){.internal-link target=_blank} ✨, esto asegura el desarrollo **continuado** y **saludable** de FastAPI y su **ecosistema**. |
|||
|
|||
Y muestra su verdadero compromiso con FastAPI y su **comunidad** (tú), ya que no solo quieren proporcionarte un **buen servicio**, sino también asegurarse de que tengas un **framework bueno y saludable**, FastAPI. 🙇 |
|||
|
|||
Podrías querer probar sus servicios y seguir sus guías: |
|||
|
|||
* <a href="https://docs.platform.sh/languages/python.html?utm_source=fastapi-signup&utm_medium=banner&utm_campaign=FastAPI-signup-June-2023" class="external-link" target="_blank">Platform.sh</a> |
|||
* <a href="https://docs.porter.run/language-specific-guides/fastapi" class="external-link" target="_blank">Porter</a> |
|||
* <a href="https://www.withcoherence.com/?utm_medium=advertising&utm_source=fastapi&utm_campaign=website" class="external-link" target="_blank">Coherence</a> |
|||
* <a href="https://docs.render.com/deploy-fastapi?utm_source=deploydoc&utm_medium=referral&utm_campaign=fastapi" class="external-link" target="_blank">Render</a> |
@ -0,0 +1,321 @@ |
|||
# Conceptos de Implementación |
|||
|
|||
Cuando implementas una aplicación **FastAPI**, o en realidad, cualquier tipo de API web, hay varios conceptos que probablemente te importen, y al entenderlos, puedes encontrar la **forma más adecuada** de **implementar tu aplicación**. |
|||
|
|||
Algunos de los conceptos importantes son: |
|||
|
|||
* Seguridad - HTTPS |
|||
* Ejecución al iniciar |
|||
* Reinicios |
|||
* Replicación (la cantidad de procesos en ejecución) |
|||
* Memoria |
|||
* Pasos previos antes de iniciar |
|||
|
|||
Veremos cómo afectan estas **implementaciones**. |
|||
|
|||
Al final, el objetivo principal es poder **servir a tus clientes de API** de una manera que sea **segura**, para **evitar interrupciones**, y usar los **recursos de cómputo** (por ejemplo, servidores remotos/máquinas virtuales) de la manera más eficiente posible. 🚀 |
|||
|
|||
Te contaré un poquito más sobre estos **conceptos** aquí, y eso, con suerte, te dará la **intuición** que necesitarías para decidir cómo implementar tu API en diferentes entornos, posiblemente incluso en aquellos **futuros** que aún no existen. |
|||
|
|||
Al considerar estos conceptos, podrás **evaluar y diseñar** la mejor manera de implementar **tus propias APIs**. |
|||
|
|||
En los próximos capítulos, te daré más **recetas concretas** para implementar aplicaciones de FastAPI. |
|||
|
|||
Pero por ahora, revisemos estas importantes **ideas conceptuales**. Estos conceptos también se aplican a cualquier otro tipo de API web. 💡 |
|||
|
|||
## Seguridad - HTTPS |
|||
|
|||
En el [capítulo anterior sobre HTTPS](https.md){.internal-link target=_blank} aprendimos sobre cómo HTTPS proporciona cifrado para tu API. |
|||
|
|||
También vimos que HTTPS es normalmente proporcionado por un componente **externo** a tu servidor de aplicaciones, un **Proxy de Terminación TLS**. |
|||
|
|||
Y debe haber algo encargado de **renovar los certificados HTTPS**, podría ser el mismo componente o algo diferente. |
|||
|
|||
### Herramientas de Ejemplo para HTTPS |
|||
|
|||
Algunas de las herramientas que podrías usar como Proxy de Terminación TLS son: |
|||
|
|||
* Traefik |
|||
* Maneja automáticamente las renovaciones de certificados ✨ |
|||
* Caddy |
|||
* Maneja automáticamente las renovaciones de certificados ✨ |
|||
* Nginx |
|||
* Con un componente externo como Certbot para las renovaciones de certificados |
|||
* HAProxy |
|||
* Con un componente externo como Certbot para las renovaciones de certificados |
|||
* Kubernetes con un Controlador de Ingress como Nginx |
|||
* Con un componente externo como cert-manager para las renovaciones de certificados |
|||
* Manejado internamente por un proveedor de nube como parte de sus servicios (lee abajo 👇) |
|||
|
|||
Otra opción es que podrías usar un **servicio de nube** que haga más del trabajo, incluyendo configurar HTTPS. Podría tener algunas restricciones o cobrarte más, etc. Pero en ese caso, no tendrías que configurar un Proxy de Terminación TLS tú mismo. |
|||
|
|||
Te mostraré algunos ejemplos concretos en los próximos capítulos. |
|||
|
|||
--- |
|||
|
|||
Luego, los siguientes conceptos a considerar son todos acerca del programa que ejecuta tu API real (por ejemplo, Uvicorn). |
|||
|
|||
## Programa y Proceso |
|||
|
|||
Hablaremos mucho sobre el "**proceso**" en ejecución, así que es útil tener claridad sobre lo que significa y cuál es la diferencia con la palabra "**programa**". |
|||
|
|||
### Qué es un Programa |
|||
|
|||
La palabra **programa** se usa comúnmente para describir muchas cosas: |
|||
|
|||
* El **código** que escribes, los **archivos Python**. |
|||
* El **archivo** que puede ser **ejecutado** por el sistema operativo, por ejemplo: `python`, `python.exe` o `uvicorn`. |
|||
* Un programa específico mientras está siendo **ejecutado** en el sistema operativo, usando la CPU y almacenando cosas en la memoria. Esto también se llama **proceso**. |
|||
|
|||
### Qué es un Proceso |
|||
|
|||
La palabra **proceso** se usa normalmente de una manera más específica, refiriéndose solo a lo que está ejecutándose en el sistema operativo (como en el último punto anterior): |
|||
|
|||
* Un programa específico mientras está siendo **ejecutado** en el sistema operativo. |
|||
* Esto no se refiere al archivo, ni al código, se refiere **específicamente** a lo que está siendo **ejecutado** y gestionado por el sistema operativo. |
|||
* Cualquier programa, cualquier código, **solo puede hacer cosas** cuando está siendo **ejecutado**. Así que, cuando hay un **proceso en ejecución**. |
|||
* El proceso puede ser **terminado** (o "matado") por ti, o por el sistema operativo. En ese punto, deja de ejecutarse/ser ejecutado, y ya no puede **hacer cosas**. |
|||
* Cada aplicación que tienes en ejecución en tu computadora tiene algún proceso detrás, cada programa en ejecución, cada ventana, etc. Y normalmente hay muchos procesos ejecutándose **al mismo tiempo** mientras una computadora está encendida. |
|||
* Puede haber **múltiples procesos** del **mismo programa** ejecutándose al mismo tiempo. |
|||
|
|||
Si revisas el "administrador de tareas" o "monitor del sistema" (o herramientas similares) en tu sistema operativo, podrás ver muchos de esos procesos en ejecución. |
|||
|
|||
Y, por ejemplo, probablemente verás que hay múltiples procesos ejecutando el mismo programa del navegador (Firefox, Chrome, Edge, etc.). Normalmente ejecutan un proceso por pestaña, además de algunos otros procesos extra. |
|||
|
|||
<img class="shadow" src="/img/deployment/concepts/image01.png"> |
|||
|
|||
--- |
|||
|
|||
Ahora que conocemos la diferencia entre los términos **proceso** y **programa**, sigamos hablando sobre implementaciones. |
|||
|
|||
## Ejecución al Iniciar |
|||
|
|||
En la mayoría de los casos, cuando creas una API web, quieres que esté **siempre en ejecución**, ininterrumpida, para que tus clientes puedan acceder a ella en cualquier momento. Esto, por supuesto, a menos que tengas una razón específica para que se ejecute solo en ciertas situaciones, pero la mayoría de las veces quieres que esté constantemente en ejecución y **disponible**. |
|||
|
|||
### En un Servidor Remoto |
|||
|
|||
Cuando configuras un servidor remoto (un servidor en la nube, una máquina virtual, etc.) lo más sencillo que puedes hacer es usar `fastapi run` (que utiliza Uvicorn) o algo similar, manualmente, de la misma manera que lo haces al desarrollar localmente. |
|||
|
|||
Y funcionará y será útil **durante el desarrollo**. |
|||
|
|||
Pero si pierdes la conexión con el servidor, el **proceso en ejecución** probablemente morirá. |
|||
|
|||
Y si el servidor se reinicia (por ejemplo, después de actualizaciones o migraciones del proveedor de la nube) probablemente **no lo notarás**. Y debido a eso, ni siquiera sabrás que tienes que reiniciar el proceso manualmente. Así, tu API simplemente quedará muerta. 😱 |
|||
|
|||
### Ejecutar Automáticamente al Iniciar |
|||
|
|||
En general, probablemente querrás que el programa del servidor (por ejemplo, Uvicorn) se inicie automáticamente al arrancar el servidor, y sin necesidad de ninguna **intervención humana**, para tener siempre un proceso en ejecución con tu API (por ejemplo, Uvicorn ejecutando tu aplicación FastAPI). |
|||
|
|||
### Programa Separado |
|||
|
|||
Para lograr esto, normalmente tendrás un **programa separado** que se asegurará de que tu aplicación se ejecute al iniciarse. Y en muchos casos, también se asegurará de que otros componentes o aplicaciones se ejecuten, por ejemplo, una base de datos. |
|||
|
|||
### Herramientas de Ejemplo para Ejecutar al Iniciar |
|||
|
|||
Algunos ejemplos de las herramientas que pueden hacer este trabajo son: |
|||
|
|||
* Docker |
|||
* Kubernetes |
|||
* Docker Compose |
|||
* Docker en Modo Swarm |
|||
* Systemd |
|||
* Supervisor |
|||
* Manejado internamente por un proveedor de nube como parte de sus servicios |
|||
* Otros... |
|||
|
|||
Te daré más ejemplos concretos en los próximos capítulos. |
|||
|
|||
## Reinicios |
|||
|
|||
De manera similar a asegurarte de que tu aplicación se ejecute al iniciar, probablemente también quieras asegurarte de que se **reinicie** después de fallos. |
|||
|
|||
### Cometemos Errores |
|||
|
|||
Nosotros, como humanos, cometemos **errores**, todo el tiempo. El software casi *siempre* tiene **bugs** ocultos en diferentes lugares. 🐛 |
|||
|
|||
Y nosotros, como desarrolladores, seguimos mejorando el código a medida que encontramos esos bugs y a medida que implementamos nuevas funcionalidades (posiblemente agregando nuevos bugs también 😅). |
|||
|
|||
### Errores Pequeños Manejados Automáticamente |
|||
|
|||
Al construir APIs web con FastAPI, si hay un error en nuestro código, FastAPI normalmente lo contiene a la solicitud única que desencadenó el error. 🛡 |
|||
|
|||
El cliente obtendrá un **500 Internal Server Error** para esa solicitud, pero la aplicación continuará funcionando para las siguientes solicitudes en lugar de simplemente colapsar por completo. |
|||
|
|||
### Errores Mayores - Colapsos |
|||
|
|||
Sin embargo, puede haber casos en los que escribamos algún código que **colapse toda la aplicación** haciendo que Uvicorn y Python colapsen. 💥 |
|||
|
|||
Y aún así, probablemente no querrías que la aplicación quede muerta porque hubo un error en un lugar, probablemente querrás que **siga ejecutándose** al menos para las *path operations* que no estén rotas. |
|||
|
|||
### Reiniciar Después del Colapso |
|||
|
|||
Pero en esos casos con errores realmente malos que colapsan el **proceso en ejecución**, querrías un componente externo encargado de **reiniciar** el proceso, al menos un par de veces... |
|||
|
|||
/// tip | Consejo |
|||
|
|||
...Aunque si la aplicación completa **colapsa inmediatamente**, probablemente no tenga sentido seguir reiniciándola eternamente. Pero en esos casos, probablemente lo notarás durante el desarrollo, o al menos justo después de la implementación. |
|||
|
|||
Así que enfoquémonos en los casos principales, donde podría colapsar por completo en algunos casos particulares **en el futuro**, y aún así tenga sentido reiniciarla. |
|||
|
|||
/// |
|||
|
|||
Probablemente querrías que la cosa encargada de reiniciar tu aplicación sea un **componente externo**, porque para ese punto, la misma aplicación con Uvicorn y Python ya colapsó, así que no hay nada en el mismo código de la misma aplicación que pueda hacer algo al respecto. |
|||
|
|||
### Herramientas de Ejemplo para Reiniciar Automáticamente |
|||
|
|||
En la mayoría de los casos, la misma herramienta que se utiliza para **ejecutar el programa al iniciar** también se utiliza para manejar reinicios automáticos. |
|||
|
|||
Por ejemplo, esto podría ser manejado por: |
|||
|
|||
* Docker |
|||
* Kubernetes |
|||
* Docker Compose |
|||
* Docker en Modo Swarm |
|||
* Systemd |
|||
* Supervisor |
|||
* Manejado internamente por un proveedor de nube como parte de sus servicios |
|||
* Otros... |
|||
|
|||
## Replicación - Procesos y Memoria |
|||
|
|||
Con una aplicación FastAPI, usando un programa servidor como el comando `fastapi` que ejecuta Uvicorn, ejecutarlo una vez en **un proceso** puede servir a múltiples clientes concurrentemente. |
|||
|
|||
Pero en muchos casos, querrás ejecutar varios worker processes al mismo tiempo. |
|||
|
|||
### Múltiples Procesos - Workers |
|||
|
|||
Si tienes más clientes de los que un solo proceso puede manejar (por ejemplo, si la máquina virtual no es muy grande) y tienes **múltiples núcleos** en la CPU del servidor, entonces podrías tener **múltiples procesos** ejecutando la misma aplicación al mismo tiempo, y distribuir todas las requests entre ellos. |
|||
|
|||
Cuando ejecutas **múltiples procesos** del mismo programa de API, comúnmente se les llama **workers**. |
|||
|
|||
### Worker Processes y Puertos |
|||
|
|||
Recuerda de la documentación [Sobre HTTPS](https.md){.internal-link target=_blank} que solo un proceso puede estar escuchando en una combinación de puerto y dirección IP en un servidor. |
|||
|
|||
Esto sigue siendo cierto. |
|||
|
|||
Así que, para poder tener **múltiples procesos** al mismo tiempo, tiene que haber un **solo proceso escuchando en un puerto** que luego transmita la comunicación a cada worker process de alguna forma. |
|||
|
|||
### Memoria por Proceso |
|||
|
|||
Ahora, cuando el programa carga cosas en memoria, por ejemplo, un modelo de machine learning en una variable, o el contenido de un archivo grande en una variable, todo eso **consume un poco de la memoria (RAM)** del servidor. |
|||
|
|||
Y múltiples procesos normalmente **no comparten ninguna memoria**. Esto significa que cada proceso en ejecución tiene sus propias cosas, variables y memoria. Y si estás consumiendo una gran cantidad de memoria en tu código, **cada proceso** consumirá una cantidad equivalente de memoria. |
|||
|
|||
### Memoria del Servidor |
|||
|
|||
Por ejemplo, si tu código carga un modelo de Machine Learning con **1 GB de tamaño**, cuando ejecutas un proceso con tu API, consumirá al menos 1 GB de RAM. Y si inicias **4 procesos** (4 workers), cada uno consumirá 1 GB de RAM. Así que, en total, tu API consumirá **4 GB de RAM**. |
|||
|
|||
Y si tu servidor remoto o máquina virtual solo tiene 3 GB de RAM, intentar cargar más de 4 GB de RAM causará problemas. 🚨 |
|||
|
|||
### Múltiples Procesos - Un Ejemplo |
|||
|
|||
En este ejemplo, hay un **Proceso Administrador** que inicia y controla dos **Worker Processes**. |
|||
|
|||
Este Proceso Administrador probablemente sería el que escuche en el **puerto** en la IP. Y transmitirá toda la comunicación a los worker processes. |
|||
|
|||
Esos worker processes serían los que ejecutan tu aplicación, realizarían los cálculos principales para recibir un **request** y devolver un **response**, y cargarían cualquier cosa que pongas en variables en RAM. |
|||
|
|||
<img src="/img/deployment/concepts/process-ram.svg"> |
|||
|
|||
Y por supuesto, la misma máquina probablemente tendría **otros procesos** ejecutándose también, aparte de tu aplicación. |
|||
|
|||
Un detalle interesante es que el porcentaje de **CPU utilizado** por cada proceso puede **variar** mucho con el tiempo, pero la **memoria (RAM)** normalmente permanece más o menos **estable**. |
|||
|
|||
Si tienes una API que hace una cantidad comparable de cálculos cada vez y tienes muchos clientes, entonces la **utilización de CPU** probablemente *también sea estable* (en lugar de constantemente subir y bajar rápidamente). |
|||
|
|||
### Ejemplos de Herramientas y Estrategias de Replicación |
|||
|
|||
Puede haber varios enfoques para lograr esto, y te contaré más sobre estrategias específicas en los próximos capítulos, por ejemplo, al hablar sobre Docker y contenedores. |
|||
|
|||
La principal restricción a considerar es que tiene que haber un **componente único** manejando el **puerto** en la **IP pública**. Y luego debe tener una forma de **transmitir** la comunicación a los **procesos/workers** replicados. |
|||
|
|||
Aquí hay algunas combinaciones y estrategias posibles: |
|||
|
|||
* **Uvicorn** con `--workers` |
|||
* Un administrador de procesos de Uvicorn **escucharía** en la **IP** y **puerto**, y iniciaría **múltiples worker processes de Uvicorn**. |
|||
* **Kubernetes** y otros sistemas de **contenedor distribuidos** |
|||
* Algo en la capa de **Kubernetes** escucharía en la **IP** y **puerto**. La replicación sería al tener **múltiples contenedores**, cada uno con **un proceso de Uvicorn** ejecutándose. |
|||
* **Servicios en la Nube** que manejan esto por ti |
|||
* El servicio en la nube probablemente **manejará la replicación por ti**. Posiblemente te permitiría definir **un proceso para ejecutar**, o una **imagen de contenedor** para usar, en cualquier caso, lo más probable es que sería **un solo proceso de Uvicorn**, y el servicio en la nube se encargaría de replicarlo. |
|||
|
|||
/// tip | Consejo |
|||
|
|||
No te preocupes si algunos de estos elementos sobre **contenedores**, Docker, o Kubernetes no tienen mucho sentido todavía. |
|||
|
|||
Te contaré más sobre imágenes de contenedores, Docker, Kubernetes, etc. en un capítulo futuro: [FastAPI en Contenedores - Docker](docker.md){.internal-link target=_blank}. |
|||
|
|||
/// |
|||
|
|||
## Pasos Previos Antes de Iniciar |
|||
|
|||
Hay muchos casos en los que quieres realizar algunos pasos **antes de iniciar** tu aplicación. |
|||
|
|||
Por ejemplo, podrías querer ejecutar **migraciones de base de datos**. |
|||
|
|||
Pero en la mayoría de los casos, querrás realizar estos pasos solo **una vez**. |
|||
|
|||
Así que, querrás tener un **único proceso** para realizar esos **pasos previos**, antes de iniciar la aplicación. |
|||
|
|||
Y tendrás que asegurarte de que sea un único proceso ejecutando esos pasos previos incluso si después, inicias **múltiples procesos** (múltiples workers) para la propia aplicación. Si esos pasos fueran ejecutados por **múltiples procesos**, **duplicarían** el trabajo al ejecutarlo en **paralelo**, y si los pasos fueran algo delicado como una migración de base de datos, podrían causar conflictos entre sí. |
|||
|
|||
Por supuesto, hay algunos casos en los que no hay problema en ejecutar los pasos previos múltiples veces, en ese caso, es mucho más fácil de manejar. |
|||
|
|||
/// tip | Consejo |
|||
|
|||
También, ten en cuenta que dependiendo de tu configuración, en algunos casos **quizás ni siquiera necesites realizar pasos previos** antes de iniciar tu aplicación. |
|||
|
|||
En ese caso, no tendrías que preocuparte por nada de esto. 🤷 |
|||
|
|||
/// |
|||
|
|||
### Ejemplos de Estrategias para Pasos Previos |
|||
|
|||
Esto **dependerá mucho** de la forma en que **implementarás tu sistema**, y probablemente estará conectado con la forma en que inicias programas, manejas reinicios, etc. |
|||
|
|||
Aquí hay algunas ideas posibles: |
|||
|
|||
* Un "Contenedor de Inicio" en Kubernetes que se ejecuta antes de tu contenedor de aplicación |
|||
* Un script de bash que ejecuta los pasos previos y luego inicia tu aplicación |
|||
* Aún necesitarías una forma de iniciar/reiniciar *ese* script de bash, detectar errores, etc. |
|||
|
|||
/// tip | Consejo |
|||
|
|||
Te daré más ejemplos concretos para hacer esto con contenedores en un capítulo futuro: [FastAPI en Contenedores - Docker](docker.md){.internal-link target=_blank}. |
|||
|
|||
/// |
|||
|
|||
## Utilización de Recursos |
|||
|
|||
Tu(s) servidor(es) es(son) un **recurso** que puedes consumir o **utilizar**, con tus programas, el tiempo de cómputo en las CPUs y la memoria RAM disponible. |
|||
|
|||
¿Cuánto de los recursos del sistema quieres consumir/utilizar? Podría ser fácil pensar "no mucho", pero en realidad, probablemente querrás consumir **lo más posible sin colapsar**. |
|||
|
|||
Si estás pagando por 3 servidores pero solo estás usando un poquito de su RAM y CPU, probablemente estés **desperdiciando dinero** 💸, y probablemente **desperdiciando la energía eléctrica del servidor** 🌎, etc. |
|||
|
|||
En ese caso, podría ser mejor tener solo 2 servidores y usar un mayor porcentaje de sus recursos (CPU, memoria, disco, ancho de banda de red, etc.). |
|||
|
|||
Por otro lado, si tienes 2 servidores y estás usando **100% de su CPU y RAM**, en algún momento un proceso pedirá más memoria y el servidor tendrá que usar el disco como "memoria" (lo cual puede ser miles de veces más lento), o incluso **colapsar**. O un proceso podría necesitar hacer algún cálculo y tendría que esperar hasta que la CPU esté libre de nuevo. |
|||
|
|||
En este caso, sería mejor obtener **un servidor extra** y ejecutar algunos procesos en él para que todos tengan **suficiente RAM y tiempo de CPU**. |
|||
|
|||
También existe la posibilidad de que, por alguna razón, tengas un **pico** de uso de tu API. Tal vez se volvió viral, o tal vez otros servicios o bots comienzan a usarla. Y podrías querer tener recursos extra para estar a salvo en esos casos. |
|||
|
|||
Podrías establecer un **número arbitrario** para alcanzar, por ejemplo, algo **entre 50% a 90%** de utilización de recursos. El punto es que esas son probablemente las principales cosas que querrás medir y usar para ajustar tus implementaciones. |
|||
|
|||
Puedes usar herramientas simples como `htop` para ver la CPU y RAM utilizadas en tu servidor o la cantidad utilizada por cada proceso. O puedes usar herramientas de monitoreo más complejas, que pueden estar distribuidas a través de servidores, etc. |
|||
|
|||
## Resumen |
|||
|
|||
Has estado leyendo aquí algunos de los conceptos principales que probablemente necesitarás tener en mente al decidir cómo implementar tu aplicación: |
|||
|
|||
* Seguridad - HTTPS |
|||
* Ejecución al iniciar |
|||
* Reinicios |
|||
* Replicación (la cantidad de procesos en ejecución) |
|||
* Memoria |
|||
* Pasos previos antes de iniciar |
|||
|
|||
Comprender estas ideas y cómo aplicarlas debería darte la intuición necesaria para tomar decisiones al configurar y ajustar tus implementaciones. 🤓 |
|||
|
|||
En las próximas secciones, te daré ejemplos más concretos de posibles estrategias que puedes seguir. 🚀 |
@ -0,0 +1,620 @@ |
|||
# FastAPI en Contenedores - Docker |
|||
|
|||
Al desplegar aplicaciones de FastAPI, un enfoque común es construir una **imagen de contenedor de Linux**. Normalmente se realiza usando <a href="https://www.docker.com/" class="external-link" target="_blank">**Docker**</a>. Luego puedes desplegar esa imagen de contenedor de varias formas. |
|||
|
|||
Usar contenedores de Linux tiene varias ventajas, incluyendo **seguridad**, **replicabilidad**, **simplicidad**, y otras. |
|||
|
|||
/// tip | Consejo |
|||
|
|||
¿Tienes prisa y ya conoces esto? Salta al [`Dockerfile` más abajo 👇](#build-a-docker-image-for-fastapi). |
|||
|
|||
/// |
|||
|
|||
<details> |
|||
<summary>Vista previa del Dockerfile 👀</summary> |
|||
|
|||
```Dockerfile |
|||
FROM python:3.9 |
|||
|
|||
WORKDIR /code |
|||
|
|||
COPY ./requirements.txt /code/requirements.txt |
|||
|
|||
RUN pip install --no-cache-dir --upgrade -r /code/requirements.txt |
|||
|
|||
COPY ./app /code/app |
|||
|
|||
CMD ["fastapi", "run", "app/main.py", "--port", "80"] |
|||
|
|||
# Si estás detrás de un proxy como Nginx o Traefik añade --proxy-headers |
|||
# CMD ["fastapi", "run", "app/main.py", "--port", "80", "--proxy-headers"] |
|||
``` |
|||
|
|||
</details> |
|||
|
|||
## Qué es un Contenedor |
|||
|
|||
Los contenedores (principalmente contenedores de Linux) son una forma muy **ligera** de empaquetar aplicaciones incluyendo todas sus dependencias y archivos necesarios, manteniéndolos aislados de otros contenedores (otras aplicaciones o componentes) en el mismo sistema. |
|||
|
|||
Los contenedores de Linux se ejecutan utilizando el mismo núcleo de Linux del host (máquina, máquina virtual, servidor en la nube, etc.). Esto significa que son muy ligeros (en comparación con las máquinas virtuales completas que emulan un sistema operativo completo). |
|||
|
|||
De esta forma, los contenedores consumen **pocos recursos**, una cantidad comparable a ejecutar los procesos directamente (una máquina virtual consumiría mucho más). |
|||
|
|||
Los contenedores también tienen sus propios procesos de ejecución **aislados** (normalmente solo un proceso), sistema de archivos y red, simplificando el despliegue, la seguridad, el desarrollo, etc. |
|||
|
|||
## Qué es una Imagen de Contenedor |
|||
|
|||
Un **contenedor** se ejecuta desde una **imagen de contenedor**. |
|||
|
|||
Una imagen de contenedor es una versión **estática** de todos los archivos, variables de entorno y el comando/programa por defecto que debería estar presente en un contenedor. **Estático** aquí significa que la imagen de contenedor **no se está ejecutando**, no está siendo ejecutada, son solo los archivos empaquetados y los metadatos. |
|||
|
|||
En contraste con una "**imagen de contenedor**" que son los contenidos estáticos almacenados, un "**contenedor**" normalmente se refiere a la instance en ejecución, lo que está siendo **ejecutado**. |
|||
|
|||
Cuando el **contenedor** se inicia y está en funcionamiento (iniciado a partir de una **imagen de contenedor**), puede crear o cambiar archivos, variables de entorno, etc. Esos cambios existirán solo en ese contenedor, pero no persistirán en la imagen de contenedor subyacente (no se guardarán en disco). |
|||
|
|||
Una imagen de contenedor es comparable al archivo de **programa** y sus contenidos, por ejemplo, `python` y algún archivo `main.py`. |
|||
|
|||
Y el **contenedor** en sí (en contraste con la **imagen de contenedor**) es la instance real en ejecución de la imagen, comparable a un **proceso**. De hecho, un contenedor solo se está ejecutando cuando tiene un **proceso en ejecución** (y normalmente es solo un proceso). El contenedor se detiene cuando no hay un proceso en ejecución en él. |
|||
|
|||
## Imágenes de Contenedor |
|||
|
|||
Docker ha sido una de las herramientas principales para crear y gestionar **imágenes de contenedor** y **contenedores**. |
|||
|
|||
Y hay un <a href="https://hub.docker.com/" class="external-link" target="_blank">Docker Hub</a> público con **imágenes de contenedores oficiales** pre-hechas para muchas herramientas, entornos, bases de datos y aplicaciones. |
|||
|
|||
Por ejemplo, hay una <a href="https://hub.docker.com/_/python" class="external-link" target="_blank">Imagen de Python</a> oficial. |
|||
|
|||
Y hay muchas otras imágenes para diferentes cosas como bases de datos, por ejemplo para: |
|||
|
|||
* <a href="https://hub.docker.com/_/postgres" class="external-link" target="_blank">PostgreSQL</a> |
|||
* <a href="https://hub.docker.com/_/mysql" class="external-link" target="_blank">MySQL</a> |
|||
* <a href="https://hub.docker.com/_/mongo" class="external-link" target="_blank">MongoDB</a> |
|||
* <a href="https://hub.docker.com/_/redis" class="external-link" target="_blank">Redis</a>, etc. |
|||
|
|||
Usando una imagen de contenedor pre-hecha es muy fácil **combinar** y utilizar diferentes herramientas. Por ejemplo, para probar una nueva base de datos. En la mayoría de los casos, puedes usar las **imágenes oficiales**, y simplemente configurarlas con variables de entorno. |
|||
|
|||
De esta manera, en muchos casos puedes aprender sobre contenedores y Docker y reutilizar ese conocimiento con muchas herramientas y componentes diferentes. |
|||
|
|||
Así, ejecutarías **múltiples contenedores** con diferentes cosas, como una base de datos, una aplicación de Python, un servidor web con una aplicación frontend en React, y conectarlos entre sí a través de su red interna. |
|||
|
|||
Todos los sistemas de gestión de contenedores (como Docker o Kubernetes) tienen estas características de redes integradas en ellos. |
|||
|
|||
## Contenedores y Procesos |
|||
|
|||
Una **imagen de contenedor** normalmente incluye en sus metadatos el programa o comando por defecto que debería ser ejecutado cuando el **contenedor** se inicie y los parámetros que deben pasar a ese programa. Muy similar a lo que sería si estuviera en la línea de comandos. |
|||
|
|||
Cuando un **contenedor** se inicia, ejecutará ese comando/programa (aunque puedes sobrescribirlo y hacer que ejecute un comando/programa diferente). |
|||
|
|||
Un contenedor está en ejecución mientras el **proceso principal** (comando o programa) esté en ejecución. |
|||
|
|||
Un contenedor normalmente tiene un **proceso único**, pero también es posible iniciar subprocesos desde el proceso principal, y de esa manera tendrás **múltiples procesos** en el mismo contenedor. |
|||
|
|||
Pero no es posible tener un contenedor en ejecución sin **al menos un proceso en ejecución**. Si el proceso principal se detiene, el contenedor se detiene. |
|||
|
|||
## Construir una Imagen de Docker para FastAPI |
|||
|
|||
¡Bien, construyamos algo ahora! 🚀 |
|||
|
|||
Te mostraré cómo construir una **imagen de Docker** para FastAPI **desde cero**, basada en la imagen **oficial de Python**. |
|||
|
|||
Esto es lo que querrías hacer en **la mayoría de los casos**, por ejemplo: |
|||
|
|||
* Usando **Kubernetes** o herramientas similares |
|||
* Al ejecutar en un **Raspberry Pi** |
|||
* Usando un servicio en la nube que ejecutaría una imagen de contenedor por ti, etc. |
|||
|
|||
### Requisitos del Paquete |
|||
|
|||
Normalmente tendrías los **requisitos del paquete** para tu aplicación en algún archivo. |
|||
|
|||
Dependería principalmente de la herramienta que uses para **instalar** esos requisitos. |
|||
|
|||
La forma más común de hacerlo es tener un archivo `requirements.txt` con los nombres de los paquetes y sus versiones, uno por línea. |
|||
|
|||
Por supuesto, usarías las mismas ideas que leíste en [Acerca de las versiones de FastAPI](versions.md){.internal-link target=_blank} para establecer los rangos de versiones. |
|||
|
|||
Por ejemplo, tu `requirements.txt` podría verse así: |
|||
|
|||
``` |
|||
fastapi[standard]>=0.113.0,<0.114.0 |
|||
pydantic>=2.7.0,<3.0.0 |
|||
``` |
|||
|
|||
Y normalmente instalarías esas dependencias de los paquetes con `pip`, por ejemplo: |
|||
|
|||
<div class="termy"> |
|||
|
|||
```console |
|||
$ pip install -r requirements.txt |
|||
---> 100% |
|||
Successfully installed fastapi pydantic |
|||
``` |
|||
|
|||
</div> |
|||
|
|||
/// info | Información |
|||
|
|||
Existen otros formatos y herramientas para definir e instalar dependencias de paquetes. |
|||
|
|||
/// |
|||
|
|||
### Crear el Código de **FastAPI** |
|||
|
|||
* Crea un directorio `app` y entra en él. |
|||
* Crea un archivo vacío `__init__.py`. |
|||
* Crea un archivo `main.py` con: |
|||
|
|||
```Python |
|||
from typing import Union |
|||
|
|||
from fastapi import FastAPI |
|||
|
|||
app = FastAPI() |
|||
|
|||
|
|||
@app.get("/") |
|||
def read_root(): |
|||
return {"Hello": "World"} |
|||
|
|||
|
|||
@app.get("/items/{item_id}") |
|||
def read_item(item_id: int, q: Union[str, None] = None): |
|||
return {"item_id": item_id, "q": q} |
|||
``` |
|||
|
|||
### Dockerfile |
|||
|
|||
Ahora, en el mismo directorio del proyecto, crea un archivo `Dockerfile` con: |
|||
|
|||
```{ .dockerfile .annotate } |
|||
# (1)! |
|||
FROM python:3.9 |
|||
|
|||
# (2)! |
|||
WORKDIR /code |
|||
|
|||
# (3)! |
|||
COPY ./requirements.txt /code/requirements.txt |
|||
|
|||
# (4)! |
|||
RUN pip install --no-cache-dir --upgrade -r /code/requirements.txt |
|||
|
|||
# (5)! |
|||
COPY ./app /code/app |
|||
|
|||
# (6)! |
|||
CMD ["fastapi", "run", "app/main.py", "--port", "80"] |
|||
``` |
|||
|
|||
1. Comenzar desde la imagen base oficial de Python. |
|||
|
|||
2. Establecer el directorio de trabajo actual a `/code`. |
|||
|
|||
Aquí es donde pondremos el archivo `requirements.txt` y el directorio `app`. |
|||
|
|||
3. Copiar el archivo con los requisitos al directorio `/code`. |
|||
|
|||
Copiar **solo** el archivo con los requisitos primero, no el resto del código. |
|||
|
|||
Como este archivo **no cambia a menudo**, Docker lo detectará y usará la **caché** para este paso, habilitando la caché para el siguiente paso también. |
|||
|
|||
4. Instalar las dependencias de los paquetes en el archivo de requisitos. |
|||
|
|||
La opción `--no-cache-dir` le dice a `pip` que no guarde los paquetes descargados localmente, ya que eso solo sería si `pip` fuese a ejecutarse de nuevo para instalar los mismos paquetes, pero ese no es el caso al trabajar con contenedores. |
|||
|
|||
/// note | Nota |
|||
|
|||
El `--no-cache-dir` está relacionado solo con `pip`, no tiene nada que ver con Docker o contenedores. |
|||
|
|||
/// |
|||
|
|||
La opción `--upgrade` le dice a `pip` que actualice los paquetes si ya están instalados. |
|||
|
|||
Debido a que el paso anterior de copiar el archivo podría ser detectado por la **caché de Docker**, este paso también **usará la caché de Docker** cuando esté disponible. |
|||
|
|||
Usar la caché en este paso te **ahorrará** mucho **tiempo** al construir la imagen una y otra vez durante el desarrollo, en lugar de **descargar e instalar** todas las dependencias **cada vez**. |
|||
|
|||
5. Copiar el directorio `./app` dentro del directorio `/code`. |
|||
|
|||
Como esto contiene todo el código, que es lo que **cambia con más frecuencia**, la **caché de Docker** no se utilizará para este u otros **pasos siguientes** fácilmente. |
|||
|
|||
Así que es importante poner esto **cerca del final** del `Dockerfile`, para optimizar los tiempos de construcción de la imagen del contenedor. |
|||
|
|||
6. Establecer el **comando** para usar `fastapi run`, que utiliza Uvicorn debajo. |
|||
|
|||
`CMD` toma una lista de cadenas, cada una de estas cadenas es lo que escribirías en la línea de comandos separado por espacios. |
|||
|
|||
Este comando se ejecutará desde el **directorio de trabajo actual**, el mismo directorio `/code` que estableciste antes con `WORKDIR /code`. |
|||
|
|||
/// tip | Consejo |
|||
|
|||
Revisa qué hace cada línea haciendo clic en cada número en la burbuja del código. 👆 |
|||
|
|||
/// |
|||
|
|||
/// warning | Advertencia |
|||
|
|||
Asegúrate de **siempre** usar la **forma exec** de la instrucción `CMD`, como se explica a continuación. |
|||
|
|||
/// |
|||
|
|||
#### Usar `CMD` - Forma Exec |
|||
|
|||
La instrucción Docker <a href="https://docs.docker.com/reference/dockerfile/#cmd" class="external-link" target="_blank">`CMD`</a> se puede escribir usando dos formas: |
|||
|
|||
✅ **Forma Exec**: |
|||
|
|||
```Dockerfile |
|||
# ✅ Haz esto |
|||
CMD ["fastapi", "run", "app/main.py", "--port", "80"] |
|||
``` |
|||
|
|||
⛔️ **Forma Shell**: |
|||
|
|||
```Dockerfile |
|||
# ⛔️ No hagas esto |
|||
CMD fastapi run app/main.py --port 80 |
|||
``` |
|||
|
|||
Asegúrate de siempre usar la **forma exec** para garantizar que FastAPI pueda cerrarse de manera adecuada y que [los eventos de lifespan](../advanced/events.md){.internal-link target=_blank} sean disparados. |
|||
|
|||
Puedes leer más sobre esto en las <a href="https://docs.docker.com/reference/dockerfile/#shell-and-exec-form" class="external-link" target="_blank">documentación de Docker para formas de shell y exec</a>. |
|||
|
|||
Esto puede ser bastante notorio al usar `docker compose`. Consulta esta sección de preguntas frecuentes de Docker Compose para más detalles técnicos: <a href="https://docs.docker.com/compose/faq/#why-do-my-services-take-10-seconds-to-recreate-or-stop" class="external-link" target="_blank">¿Por qué mis servicios tardan 10 segundos en recrearse o detenerse?</a>. |
|||
|
|||
#### Estructura de Directorios |
|||
|
|||
Ahora deberías tener una estructura de directorios como: |
|||
|
|||
``` |
|||
. |
|||
├── app |
|||
│ ├── __init__.py |
|||
│ └── main.py |
|||
├── Dockerfile |
|||
└── requirements.txt |
|||
``` |
|||
|
|||
#### Detrás de un Proxy de Terminación TLS |
|||
|
|||
Si estás ejecutando tu contenedor detrás de un Proxy de Terminación TLS (load balancer) como Nginx o Traefik, añade la opción `--proxy-headers`, esto le dirá a Uvicorn (a través de la CLI de FastAPI) que confíe en los headers enviados por ese proxy indicando que la aplicación se está ejecutando detrás de HTTPS, etc. |
|||
|
|||
```Dockerfile |
|||
CMD ["fastapi", "run", "app/main.py", "--proxy-headers", "--port", "80"] |
|||
``` |
|||
|
|||
#### Cache de Docker |
|||
|
|||
Hay un truco importante en este `Dockerfile`, primero copiamos **el archivo con las dependencias solo**, no el resto del código. Déjame decirte por qué es así. |
|||
|
|||
```Dockerfile |
|||
COPY ./requirements.txt /code/requirements.txt |
|||
``` |
|||
|
|||
Docker y otras herramientas **construyen** estas imágenes de contenedor **incrementalmente**, añadiendo **una capa sobre la otra**, empezando desde la parte superior del `Dockerfile` y añadiendo cualquier archivo creado por cada una de las instrucciones del `Dockerfile`. |
|||
|
|||
Docker y herramientas similares también usan una **caché interna** al construir la imagen, si un archivo no ha cambiado desde la última vez que se construyó la imagen del contenedor, entonces reutilizará la misma capa creada la última vez, en lugar de copiar el archivo de nuevo y crear una nueva capa desde cero. |
|||
|
|||
Solo evitar copiar archivos no mejora necesariamente las cosas mucho, pero porque se usó la caché para ese paso, puede **usar la caché para el siguiente paso**. Por ejemplo, podría usar la caché para la instrucción que instala las dependencias con: |
|||
|
|||
```Dockerfile |
|||
RUN pip install --no-cache-dir --upgrade -r /code/requirements.txt |
|||
``` |
|||
|
|||
El archivo con los requisitos de los paquetes **no cambiará con frecuencia**. Así que, al copiar solo ese archivo, Docker podrá **usar la caché** para ese paso. |
|||
|
|||
Y luego, Docker podrá **usar la caché para el siguiente paso** que descarga e instala esas dependencias. Y aquí es donde **ahorramos mucho tiempo**. ✨ ...y evitamos el aburrimiento de esperar. 😪😆 |
|||
|
|||
Descargar e instalar las dependencias de los paquetes **podría llevar minutos**, pero usando la **caché** tomaría **segundos** como máximo. |
|||
|
|||
Y como estarías construyendo la imagen del contenedor una y otra vez durante el desarrollo para comprobar que los cambios en tu código funcionan, hay una gran cantidad de tiempo acumulado que te ahorrarías. |
|||
|
|||
Luego, cerca del final del `Dockerfile`, copiamos todo el código. Como esto es lo que **cambia con más frecuencia**, lo ponemos cerca del final, porque casi siempre, cualquier cosa después de este paso no podrá usar la caché. |
|||
|
|||
```Dockerfile |
|||
COPY ./app /code/app |
|||
``` |
|||
|
|||
### Construir la Imagen de Docker |
|||
|
|||
Ahora que todos los archivos están en su lugar, vamos a construir la imagen del contenedor. |
|||
|
|||
* Ve al directorio del proyecto (donde está tu `Dockerfile`, conteniendo tu directorio `app`). |
|||
* Construye tu imagen de FastAPI: |
|||
|
|||
<div class="termy"> |
|||
|
|||
```console |
|||
$ docker build -t myimage . |
|||
|
|||
---> 100% |
|||
``` |
|||
|
|||
</div> |
|||
|
|||
/// tip | Consejo |
|||
|
|||
Fíjate en el `.` al final, es equivalente a `./`, le indica a Docker el directorio a usar para construir la imagen del contenedor. |
|||
|
|||
En este caso, es el mismo directorio actual (`.`). |
|||
|
|||
/// |
|||
|
|||
### Iniciar el Contenedor Docker |
|||
|
|||
* Ejecuta un contenedor basado en tu imagen: |
|||
|
|||
<div class="termy"> |
|||
|
|||
```console |
|||
$ docker run -d --name mycontainer -p 80:80 myimage |
|||
``` |
|||
|
|||
</div> |
|||
|
|||
## Revísalo |
|||
|
|||
Deberías poder revisarlo en la URL de tu contenedor de Docker, por ejemplo: <a href="http://192.168.99.100/items/5?q=somequery" class="external-link" target="_blank">http://192.168.99.100/items/5?q=somequery</a> o <a href="http://127.0.0.1/items/5?q=somequery" class="external-link" target="_blank">http://127.0.0.1/items/5?q=somequery</a> (o equivalente, usando tu host de Docker). |
|||
|
|||
Verás algo como: |
|||
|
|||
```JSON |
|||
{"item_id": 5, "q": "somequery"} |
|||
``` |
|||
|
|||
## Documentación Interactiva de la API |
|||
|
|||
Ahora puedes ir a <a href="http://192.168.99.100/docs" class="external-link" target="_blank">http://192.168.99.100/docs</a> o <a href="http://127.0.0.1/docs" class="external-link" target="_blank">http://127.0.0.1/docs</a> (o equivalente, usando tu host de Docker). |
|||
|
|||
Verás la documentación interactiva automática de la API (proporcionada por <a href="https://github.com/swagger-api/swagger-ui" class="external-link" target="_blank">Swagger UI</a>): |
|||
|
|||
 |
|||
|
|||
## Documentación Alternativa de la API |
|||
|
|||
Y también puedes ir a <a href="http://192.168.99.100/redoc" class="external-link" target="_blank">http://192.168.99.100/redoc</a> o <a href="http://127.0.0.1/redoc" class="external-link" target="_blank">http://127.0.0.1/redoc</a> (o equivalente, usando tu host de Docker). |
|||
|
|||
Verás la documentación alternativa automática (proporcionada por <a href="https://github.com/Rebilly/ReDoc" class="external-link" target="_blank">ReDoc</a>): |
|||
|
|||
 |
|||
|
|||
## Construir una Imagen de Docker con un FastAPI de Un Solo Archivo |
|||
|
|||
Si tu FastAPI es un solo archivo, por ejemplo, `main.py` sin un directorio `./app`, tu estructura de archivos podría verse así: |
|||
|
|||
``` |
|||
. |
|||
├── Dockerfile |
|||
├── main.py |
|||
└── requirements.txt |
|||
``` |
|||
|
|||
Entonces solo tendrías que cambiar las rutas correspondientes para copiar el archivo dentro del `Dockerfile`: |
|||
|
|||
```{ .dockerfile .annotate hl_lines="10 13" } |
|||
FROM python:3.9 |
|||
|
|||
WORKDIR /code |
|||
|
|||
COPY ./requirements.txt /code/requirements.txt |
|||
|
|||
RUN pip install --no-cache-dir --upgrade -r /code/requirements.txt |
|||
|
|||
# (1)! |
|||
COPY ./main.py /code/ |
|||
|
|||
# (2)! |
|||
CMD ["fastapi", "run", "main.py", "--port", "80"] |
|||
``` |
|||
|
|||
1. Copia el archivo `main.py` directamente al directorio `/code` (sin ningún directorio `./app`). |
|||
|
|||
2. Usa `fastapi run` para servir tu aplicación en el archivo único `main.py`. |
|||
|
|||
Cuando pasas el archivo a `fastapi run`, detectará automáticamente que es un archivo único y no parte de un paquete y sabrá cómo importarlo y servir tu aplicación FastAPI. 😎 |
|||
|
|||
## Conceptos de Despliegue |
|||
|
|||
Hablemos nuevamente de algunos de los mismos [Conceptos de Despliegue](concepts.md){.internal-link target=_blank} en términos de contenedores. |
|||
|
|||
Los contenedores son principalmente una herramienta para simplificar el proceso de **construcción y despliegue** de una aplicación, pero no imponen un enfoque particular para manejar estos **conceptos de despliegue**, y hay varias estrategias posibles. |
|||
|
|||
La **buena noticia** es que con cada estrategia diferente hay una forma de cubrir todos los conceptos de despliegue. 🎉 |
|||
|
|||
Revisemos estos **conceptos de despliegue** en términos de contenedores: |
|||
|
|||
* HTTPS |
|||
* Ejecutar en el inicio |
|||
* Reinicios |
|||
* Replicación (el número de procesos en ejecución) |
|||
* Memoria |
|||
* Pasos previos antes de comenzar |
|||
|
|||
## HTTPS |
|||
|
|||
Si nos enfocamos solo en la **imagen de contenedor** para una aplicación FastAPI (y luego el **contenedor** en ejecución), HTTPS normalmente sería manejado **externamente** por otra herramienta. |
|||
|
|||
Podría ser otro contenedor, por ejemplo, con <a href="https://traefik.io/" class="external-link" target="_blank">Traefik</a>, manejando **HTTPS** y la adquisición **automática** de **certificados**. |
|||
|
|||
/// tip | Consejo |
|||
|
|||
Traefik tiene integraciones con Docker, Kubernetes, y otros, por lo que es muy fácil configurar y configurar HTTPS para tus contenedores con él. |
|||
|
|||
/// |
|||
|
|||
Alternativamente, HTTPS podría ser manejado por un proveedor de la nube como uno de sus servicios (mientras que la aplicación aún se ejecuta en un contenedor). |
|||
|
|||
## Ejecutar en el Inicio y Reinicios |
|||
|
|||
Normalmente hay otra herramienta encargada de **iniciar y ejecutar** tu contenedor. |
|||
|
|||
Podría ser **Docker** directamente, **Docker Compose**, **Kubernetes**, un **servicio en la nube**, etc. |
|||
|
|||
En la mayoría (o todas) de las casos, hay una opción sencilla para habilitar la ejecución del contenedor al inicio y habilitar los reinicios en caso de fallos. Por ejemplo, en Docker, es la opción de línea de comandos `--restart`. |
|||
|
|||
Sin usar contenedores, hacer que las aplicaciones se ejecuten al inicio y con reinicios puede ser engorroso y difícil. Pero al **trabajar con contenedores** en la mayoría de los casos, esa funcionalidad se incluye por defecto. ✨ |
|||
|
|||
## Replicación - Número de Procesos |
|||
|
|||
Si tienes un <abbr title="Un grupo de máquinas que están configuradas para estar conectadas y trabajar juntas de alguna manera.">cluster</abbr> de máquinas con **Kubernetes**, Docker Swarm Mode, Nomad, u otro sistema complejo similar para gestionar contenedores distribuidos en varias máquinas, entonces probablemente querrás manejar la **replicación** a nivel de **cluster** en lugar de usar un **gestor de procesos** (como Uvicorn con workers) en cada contenedor. |
|||
|
|||
Uno de esos sistemas de gestión de contenedores distribuidos como Kubernetes normalmente tiene alguna forma integrada de manejar la **replicación de contenedores** mientras aún soporta el **load balancing** para las requests entrantes. Todo a nivel de **cluster**. |
|||
|
|||
En esos casos, probablemente desearías construir una **imagen de Docker desde cero** como se [explica arriba](#dockerfile), instalando tus dependencias, y ejecutando **un solo proceso de Uvicorn** en lugar de usar múltiples workers de Uvicorn. |
|||
|
|||
### Load Balancer |
|||
|
|||
Al usar contenedores, normalmente tendrías algún componente **escuchando en el puerto principal**. Podría posiblemente ser otro contenedor que es también un **Proxy de Terminación TLS** para manejar **HTTPS** o alguna herramienta similar. |
|||
|
|||
Como este componente tomaría la **carga** de las requests y las distribuiría entre los workers de una manera (esperablemente) **balanceada**, también se le llama comúnmente **Load Balancer**. |
|||
|
|||
/// tip | Consejo |
|||
|
|||
El mismo componente **Proxy de Terminación TLS** usado para HTTPS probablemente también sería un **Load Balancer**. |
|||
|
|||
/// |
|||
|
|||
Y al trabajar con contenedores, el mismo sistema que usas para iniciarlos y gestionarlos ya tendría herramientas internas para transmitir la **comunicación en red** (e.g., requests HTTP) desde ese **load balancer** (que también podría ser un **Proxy de Terminación TLS**) a los contenedores con tu aplicación. |
|||
|
|||
### Un Load Balancer - Múltiples Contenedores Worker |
|||
|
|||
Al trabajar con **Kubernetes** u otros sistemas de gestión de contenedores distribuidos similares, usar sus mecanismos de red internos permitiría que el único **load balancer** que está escuchando en el **puerto** principal transmita la comunicación (requests) a posiblemente **múltiples contenedores** ejecutando tu aplicación. |
|||
|
|||
Cada uno de estos contenedores ejecutando tu aplicación normalmente tendría **solo un proceso** (e.g., un proceso Uvicorn ejecutando tu aplicación FastAPI). Todos serían **contenedores idénticos**, ejecutando lo mismo, pero cada uno con su propio proceso, memoria, etc. De esa forma, aprovecharías la **paralelización** en **diferentes núcleos** de la CPU, o incluso en **diferentes máquinas**. |
|||
|
|||
Y el sistema de contenedores distribuido con el **load balancer** **distribuiría las requests** a cada uno de los contenedores **replicados** que ejecutan tu aplicación **en turnos**. Así, cada request podría ser manejado por uno de los múltiples **contenedores replicados** ejecutando tu aplicación. |
|||
|
|||
Y normalmente este **load balancer** podría manejar requests que vayan a *otras* aplicaciones en tu cluster (p. ej., a un dominio diferente, o bajo un prefijo de ruta de URL diferente), y transmitiría esa comunicación a los contenedores correctos para *esa otra* aplicación ejecutándose en tu cluster. |
|||
|
|||
### Un Proceso por Contenedor |
|||
|
|||
En este tipo de escenario, probablemente querrías tener **un solo proceso (Uvicorn) por contenedor**, ya que ya estarías manejando la replicación a nivel de cluster. |
|||
|
|||
Así que, en este caso, **no** querrías tener múltiples workers en el contenedor, por ejemplo, con la opción de línea de comandos `--workers`. Querrías tener solo un **proceso Uvicorn por contenedor** (pero probablemente múltiples contenedores). |
|||
|
|||
Tener otro gestor de procesos dentro del contenedor (como sería con múltiples workers) solo añadiría **complejidad innecesaria** que probablemente ya estés manejando con tu sistema de cluster. |
|||
|
|||
### Contenedores con Múltiples Procesos y Casos Especiales |
|||
|
|||
Por supuesto, hay **casos especiales** donde podrías querer tener **un contenedor** con varios **worker processes de Uvicorn** dentro. |
|||
|
|||
En esos casos, puedes usar la opción de línea de comandos `--workers` para establecer el número de workers que deseas ejecutar: |
|||
|
|||
```{ .dockerfile .annotate } |
|||
FROM python:3.9 |
|||
|
|||
WORKDIR /code |
|||
|
|||
COPY ./requirements.txt /code/requirements.txt |
|||
|
|||
RUN pip install --no-cache-dir --upgrade -r /code/requirements.txt |
|||
|
|||
COPY ./app /code/app |
|||
|
|||
# (1)! |
|||
CMD ["fastapi", "run", "app/main.py", "--port", "80", "--workers", "4"] |
|||
``` |
|||
|
|||
1. Aquí usamos la opción de línea de comandos `--workers` para establecer el número de workers a 4. |
|||
|
|||
Aquí hay algunos ejemplos de cuándo eso podría tener sentido: |
|||
|
|||
#### Una Aplicación Simple |
|||
|
|||
Podrías querer un gestor de procesos en el contenedor si tu aplicación es **lo suficientemente simple** que pueda ejecutarse en un **servidor único**, no un cluster. |
|||
|
|||
#### Docker Compose |
|||
|
|||
Podrías estar desplegando en un **servidor único** (no un cluster) con **Docker Compose**, por lo que no tendrías una forma fácil de gestionar la replicación de contenedores (con Docker Compose) mientras se preserva la red compartida y el **load balancing**. |
|||
|
|||
Entonces podrías querer tener **un solo contenedor** con un **gestor de procesos** iniciando **varios worker processes** dentro. |
|||
|
|||
--- |
|||
|
|||
El punto principal es que, **ninguna** de estas son **reglas escritas en piedra** que debas seguir a ciegas. Puedes usar estas ideas para **evaluar tu propio caso de uso** y decidir cuál es el mejor enfoque para tu sistema, verificando cómo gestionar los conceptos de: |
|||
|
|||
* Seguridad - HTTPS |
|||
* Ejecutar en el inicio |
|||
* Reinicios |
|||
* Replicación (el número de procesos en ejecución) |
|||
* Memoria |
|||
* Pasos previos antes de comenzar |
|||
|
|||
## Memoria |
|||
|
|||
Si ejecutas **un solo proceso por contenedor**, tendrás una cantidad de memoria más o menos bien definida, estable y limitada consumida por cada uno de esos contenedores (más de uno si están replicados). |
|||
|
|||
Y luego puedes establecer esos mismos límites de memoria y requisitos en tus configuraciones para tu sistema de gestión de contenedores (por ejemplo, en **Kubernetes**). De esa manera, podrá **replicar los contenedores** en las **máquinas disponibles** teniendo en cuenta la cantidad de memoria necesaria por ellos, y la cantidad disponible en las máquinas en el cluster. |
|||
|
|||
Si tu aplicación es **simple**, probablemente esto **no será un problema**, y puede que no necesites especificar límites de memoria estrictos. Pero si estás **usando mucha memoria** (por ejemplo, con modelos de **Machine Learning**), deberías verificar cuánta memoria estás consumiendo y ajustar el **número de contenedores** que se ejecutan en **cada máquina** (y tal vez agregar más máquinas a tu cluster). |
|||
|
|||
Si ejecutas **múltiples procesos por contenedor**, tendrás que asegurarte de que el número de procesos iniciados no **consuma más memoria** de la que está disponible. |
|||
|
|||
## Pasos Previos Antes de Comenzar y Contenedores |
|||
|
|||
Si estás usando contenedores (por ejemplo, Docker, Kubernetes), entonces hay dos enfoques principales que puedes usar. |
|||
|
|||
### Múltiples Contenedores |
|||
|
|||
Si tienes **múltiples contenedores**, probablemente cada uno ejecutando un **proceso único** (por ejemplo, en un cluster de **Kubernetes**), entonces probablemente querrías tener un **contenedor separado** realizando el trabajo de los **pasos previos** en un solo contenedor, ejecutando un solo proceso, **antes** de ejecutar los contenedores worker replicados. |
|||
|
|||
/// info | Información |
|||
|
|||
Si estás usando Kubernetes, probablemente sería un <a href="https://kubernetes.io/docs/concepts/workloads/pods/init-containers/" class="external-link" target="_blank">Contenedor de Inicialización</a>. |
|||
|
|||
/// |
|||
|
|||
Si en tu caso de uso no hay problema en ejecutar esos pasos previos **múltiples veces en paralelo** (por ejemplo, si no estás ejecutando migraciones de base de datos, sino simplemente verificando si la base de datos está lista), entonces también podrías simplemente ponerlos en cada contenedor justo antes de iniciar el proceso principal. |
|||
|
|||
### Un Contenedor Único |
|||
|
|||
Si tienes una configuración simple, con un **contenedor único** que luego inicia múltiples **worker processes** (o también solo un proceso), entonces podrías ejecutar esos pasos previos en el mismo contenedor, justo antes de iniciar el proceso con la aplicación. |
|||
|
|||
### Imagen Base de Docker |
|||
|
|||
Solía haber una imagen official de Docker de FastAPI: <a href="https://github.com/tiangolo/uvicorn-gunicorn-fastapi-docker" class="external-link" target="_blank">tiangolo/uvicorn-gunicorn-fastapi</a>. Pero ahora está obsoleta. ⛔️ |
|||
|
|||
Probablemente **no** deberías usar esta imagen base de Docker (o cualquier otra similar). |
|||
|
|||
Si estás usando **Kubernetes** (u otros) y ya estás configurando la **replicación** a nivel de cluster, con múltiples **contenedores**. En esos casos, es mejor que **construyas una imagen desde cero** como se describe arriba: [Construir una Imagen de Docker para FastAPI](#build-a-docker-image-for-fastapi). |
|||
|
|||
Y si necesitas tener múltiples workers, puedes simplemente utilizar la opción de línea de comandos `--workers`. |
|||
|
|||
/// note | Detalles Técnicos |
|||
|
|||
La imagen de Docker se creó cuando Uvicorn no soportaba gestionar y reiniciar workers muertos, por lo que era necesario usar Gunicorn con Uvicorn, lo que añadía bastante complejidad, solo para que Gunicorn gestionara y reiniciara los worker processes de Uvicorn. |
|||
|
|||
Pero ahora que Uvicorn (y el comando `fastapi`) soportan el uso de `--workers`, no hay razón para utilizar una imagen base de Docker en lugar de construir la tuya propia (es prácticamente la misma cantidad de código 😅). |
|||
|
|||
/// |
|||
|
|||
## Desplegar la Imagen del Contenedor |
|||
|
|||
Después de tener una Imagen de Contenedor (Docker) hay varias maneras de desplegarla. |
|||
|
|||
Por ejemplo: |
|||
|
|||
* Con **Docker Compose** en un servidor único |
|||
* Con un cluster de **Kubernetes** |
|||
* Con un cluster de Docker Swarm Mode |
|||
* Con otra herramienta como Nomad |
|||
* Con un servicio en la nube que tome tu imagen de contenedor y la despliegue |
|||
|
|||
## Imagen de Docker con `uv` |
|||
|
|||
Si estás usando <a href="https://github.com/astral-sh/uv" class="external-link" target="_blank">uv</a> para instalar y gestionar tu proyecto, puedes seguir su <a href="https://docs.astral.sh/uv/guides/integration/docker/" class="external-link" target="_blank">guía de Docker de uv</a>. |
|||
|
|||
## Resumen |
|||
|
|||
Usando sistemas de contenedores (por ejemplo, con **Docker** y **Kubernetes**) se vuelve bastante sencillo manejar todos los **conceptos de despliegue**: |
|||
|
|||
* HTTPS |
|||
* Ejecutar en el inicio |
|||
* Reinicios |
|||
* Replicación (el número de procesos en ejecución) |
|||
* Memoria |
|||
* Pasos previos antes de comenzar |
|||
|
|||
En la mayoría de los casos, probablemente no querrás usar ninguna imagen base, y en su lugar **construir una imagen de contenedor desde cero** basada en la imagen oficial de Docker de Python. |
|||
|
|||
Teniendo en cuenta el **orden** de las instrucciones en el `Dockerfile` y la **caché de Docker** puedes **minimizar los tiempos de construcción**, para maximizar tu productividad (y evitar el aburrimiento). 😎 |
@ -0,0 +1,199 @@ |
|||
# Sobre HTTPS |
|||
|
|||
Es fácil asumir que HTTPS es algo que simplemente está "activado" o no. |
|||
|
|||
Pero es mucho más complejo que eso. |
|||
|
|||
/// tip | Consejo |
|||
|
|||
Si tienes prisa o no te importa, continúa con las siguientes secciones para ver instrucciones paso a paso para configurar todo con diferentes técnicas. |
|||
|
|||
/// |
|||
|
|||
Para **aprender los conceptos básicos de HTTPS**, desde una perspectiva de consumidor, revisa <a href="https://howhttps.works/" class="external-link" target="_blank">https://howhttps.works/</a>. |
|||
|
|||
Ahora, desde una **perspectiva de desarrollador**, aquí hay varias cosas a tener en cuenta al pensar en HTTPS: |
|||
|
|||
* Para HTTPS, **el servidor** necesita **tener "certificados"** generados por un **tercero**. |
|||
* Esos certificados en realidad son **adquiridos** del tercero, no "generados". |
|||
* Los certificados tienen una **vida útil**. |
|||
* Ellos **expiran**. |
|||
* Y luego necesitan ser **renovados**, **adquiridos nuevamente** del tercero. |
|||
* La encriptación de la conexión ocurre a nivel de **TCP**. |
|||
* Esa es una capa **debajo de HTTP**. |
|||
* Por lo tanto, el manejo de **certificados y encriptación** se realiza **antes de HTTP**. |
|||
* **TCP no sabe acerca de "dominios"**. Solo sobre direcciones IP. |
|||
* La información sobre el **dominio específico** solicitado va en los **datos HTTP**. |
|||
* Los **certificados HTTPS** "certifican" un **cierto dominio**, pero el protocolo y la encriptación ocurren a nivel de TCP, **antes de saber** con cuál dominio se está tratando. |
|||
* **Por defecto**, eso significaría que solo puedes tener **un certificado HTTPS por dirección IP**. |
|||
* No importa cuán grande sea tu servidor o qué tan pequeña pueda ser cada aplicación que tengas en él. |
|||
* Sin embargo, hay una **solución** para esto. |
|||
* Hay una **extensión** para el protocolo **TLS** (el que maneja la encriptación a nivel de TCP, antes de HTTP) llamada **<a href="https://en.wikipedia.org/wiki/Server_Name_Indication" class="external-link" target="_blank"><abbr title="Server Name Indication">SNI</abbr></a>**. |
|||
* Esta extensión SNI permite que un solo servidor (con una **sola dirección IP**) tenga **varios certificados HTTPS** y sirva **múltiples dominios/aplicaciones HTTPS**. |
|||
* Para que esto funcione, un componente (programa) **único** que se ejecute en el servidor, escuchando en la **dirección IP pública**, debe tener **todos los certificados HTTPS** en el servidor. |
|||
* **Después** de obtener una conexión segura, el protocolo de comunicación sigue siendo **HTTP**. |
|||
* Los contenidos están **encriptados**, aunque se envién con el **protocolo HTTP**. |
|||
|
|||
Es una práctica común tener **un programa/servidor HTTP** ejecutándose en el servidor (la máquina, host, etc.) y **gestionando todas las partes de HTTPS**: recibiendo los **requests HTTPS encriptados**, enviando los **requests HTTP desencriptados** a la aplicación HTTP real que se ejecuta en el mismo servidor (la aplicación **FastAPI**, en este caso), tomando el **response HTTP** de la aplicación, **encriptándolo** usando el **certificado HTTPS** adecuado y enviándolo de vuelta al cliente usando **HTTPS**. Este servidor a menudo se llama un **<a href="https://en.wikipedia.org/wiki/TLS_termination_proxy" class="external-link" target="_blank">TLS Termination Proxy</a>**. |
|||
|
|||
Algunas de las opciones que podrías usar como un TLS Termination Proxy son: |
|||
|
|||
* Traefik (que también puede manejar la renovación de certificados) |
|||
* Caddy (que también puede manejar la renovación de certificados) |
|||
* Nginx |
|||
* HAProxy |
|||
|
|||
## Let's Encrypt |
|||
|
|||
Antes de Let's Encrypt, estos **certificados HTTPS** eran vendidos por terceros. |
|||
|
|||
El proceso para adquirir uno de estos certificados solía ser complicado, requerir bastante papeleo y los certificados eran bastante costosos. |
|||
|
|||
Pero luego se creó **<a href="https://letsencrypt.org/" class="external-link" target="_blank">Let's Encrypt</a>**. |
|||
|
|||
Es un proyecto de la Linux Foundation. Proporciona **certificados HTTPS de forma gratuita**, de manera automatizada. Estos certificados usan toda la seguridad criptográfica estándar, y tienen una corta duración (aproximadamente 3 meses), por lo que la **seguridad es en realidad mejor** debido a su corta vida útil. |
|||
|
|||
Los dominios son verificados de manera segura y los certificados se generan automáticamente. Esto también permite automatizar la renovación de estos certificados. |
|||
|
|||
La idea es automatizar la adquisición y renovación de estos certificados para que puedas tener **HTTPS seguro, gratuito, para siempre**. |
|||
|
|||
## HTTPS para Desarrolladores |
|||
|
|||
Aquí tienes un ejemplo de cómo podría ser una API HTTPS, paso a paso, prestando atención principalmente a las ideas importantes para los desarrolladores. |
|||
|
|||
### Nombre de Dominio |
|||
|
|||
Probablemente todo comenzaría adquiriendo un **nombre de dominio**. Luego, lo configurarías en un servidor DNS (posiblemente tu mismo proveedor de la nube). |
|||
|
|||
Probablemente conseguirías un servidor en la nube (una máquina virtual) o algo similar, y tendría una **dirección IP pública** <abbr title="Que no cambia">fija</abbr>. |
|||
|
|||
En el/los servidor(es) DNS configurarías un registro (un "`A record`") para apuntar **tu dominio** a la **dirección IP pública de tu servidor**. |
|||
|
|||
Probablemente harías esto solo una vez, la primera vez, al configurar todo. |
|||
|
|||
/// tip | Consejo |
|||
|
|||
Esta parte del Nombre de Dominio es mucho antes de HTTPS, pero como todo depende del dominio y la dirección IP, vale la pena mencionarlo aquí. |
|||
|
|||
/// |
|||
|
|||
### DNS |
|||
|
|||
Ahora centrémonos en todas las partes realmente de HTTPS. |
|||
|
|||
Primero, el navegador consultaría con los **servidores DNS** cuál es la **IP del dominio**, en este caso, `someapp.example.com`. |
|||
|
|||
Los servidores DNS le dirían al navegador que use una **dirección IP** específica. Esa sería la dirección IP pública utilizada por tu servidor, que configuraste en los servidores DNS. |
|||
|
|||
<img src="/img/deployment/https/https01.svg"> |
|||
|
|||
### Inicio del Handshake TLS |
|||
|
|||
El navegador luego se comunicaría con esa dirección IP en el **puerto 443** (el puerto HTTPS). |
|||
|
|||
La primera parte de la comunicación es solo para establecer la conexión entre el cliente y el servidor y decidir las claves criptográficas que usarán, etc. |
|||
|
|||
<img src="/img/deployment/https/https02.svg"> |
|||
|
|||
Esta interacción entre el cliente y el servidor para establecer la conexión TLS se llama **handshake TLS**. |
|||
|
|||
### TLS con Extensión SNI |
|||
|
|||
**Solo un proceso** en el servidor puede estar escuchando en un **puerto** específico en una **dirección IP** específica. Podría haber otros procesos escuchando en otros puertos en la misma dirección IP, pero solo uno para cada combinación de dirección IP y puerto. |
|||
|
|||
TLS (HTTPS) utiliza el puerto específico `443` por defecto. Así que ese es el puerto que necesitaríamos. |
|||
|
|||
Como solo un proceso puede estar escuchando en este puerto, el proceso que lo haría sería el **TLS Termination Proxy**. |
|||
|
|||
El TLS Termination Proxy tendría acceso a uno o más **certificados TLS** (certificados HTTPS). |
|||
|
|||
Usando la **extensión SNI** discutida anteriormente, el TLS Termination Proxy verificaría cuál de los certificados TLS (HTTPS) disponibles debería usar para esta conexión, usando el que coincida con el dominio esperado por el cliente. |
|||
|
|||
En este caso, usaría el certificado para `someapp.example.com`. |
|||
|
|||
<img src="/img/deployment/https/https03.svg"> |
|||
|
|||
El cliente ya **confía** en la entidad que generó ese certificado TLS (en este caso Let's Encrypt, pero lo veremos más adelante), por lo que puede **verificar** que el certificado sea válido. |
|||
|
|||
Luego, usando el certificado, el cliente y el TLS Termination Proxy **deciden cómo encriptar** el resto de la **comunicación TCP**. Esto completa la parte de **Handshake TLS**. |
|||
|
|||
Después de esto, el cliente y el servidor tienen una **conexión TCP encriptada**, esto es lo que proporciona TLS. Y luego pueden usar esa conexión para iniciar la comunicación **HTTP real**. |
|||
|
|||
Y eso es lo que es **HTTPS**, es simplemente HTTP simple **dentro de una conexión TLS segura** en lugar de una conexión TCP pura (sin encriptar). |
|||
|
|||
/// tip | Consejo |
|||
|
|||
Ten en cuenta que la encriptación de la comunicación ocurre a nivel de **TCP**, no a nivel de HTTP. |
|||
|
|||
/// |
|||
|
|||
### Request HTTPS |
|||
|
|||
Ahora que el cliente y el servidor (específicamente el navegador y el TLS Termination Proxy) tienen una **conexión TCP encriptada**, pueden iniciar la **comunicación HTTP**. |
|||
|
|||
Así que, el cliente envía un **request HTTPS**. Esto es simplemente un request HTTP a través de una conexión TLS encriptada. |
|||
|
|||
<img src="/img/deployment/https/https04.svg"> |
|||
|
|||
### Desencriptar el Request |
|||
|
|||
El TLS Termination Proxy usaría la encriptación acordada para **desencriptar el request**, y transmitiría el **request HTTP simple (desencriptado)** al proceso que ejecuta la aplicación (por ejemplo, un proceso con Uvicorn ejecutando la aplicación FastAPI). |
|||
|
|||
<img src="/img/deployment/https/https05.svg"> |
|||
|
|||
### Response HTTP |
|||
|
|||
La aplicación procesaría el request y enviaría un **response HTTP simple (sin encriptar)** al TLS Termination Proxy. |
|||
|
|||
<img src="/img/deployment/https/https06.svg"> |
|||
|
|||
### Response HTTPS |
|||
|
|||
El TLS Termination Proxy entonces **encriptaría el response** usando la criptografía acordada antes (que comenzó con el certificado para `someapp.example.com`), y lo enviaría de vuelta al navegador. |
|||
|
|||
Luego, el navegador verificaría que el response sea válido y encriptado con la clave criptográfica correcta, etc. Entonces **desencriptaría el response** y lo procesaría. |
|||
|
|||
<img src="/img/deployment/https/https07.svg"> |
|||
|
|||
El cliente (navegador) sabrá que el response proviene del servidor correcto porque está utilizando la criptografía que acordaron usando el **certificado HTTPS** anteriormente. |
|||
|
|||
### Múltiples Aplicaciones |
|||
|
|||
En el mismo servidor (o servidores), podrían haber **múltiples aplicaciones**, por ejemplo, otros programas API o una base de datos. |
|||
|
|||
Solo un proceso puede estar gestionando la IP y puerto específica (el TLS Termination Proxy en nuestro ejemplo) pero las otras aplicaciones/procesos pueden estar ejecutándose en el/los servidor(es) también, siempre y cuando no intenten usar la misma **combinación de IP pública y puerto**. |
|||
|
|||
<img src="/img/deployment/https/https08.svg"> |
|||
|
|||
De esa manera, el TLS Termination Proxy podría gestionar HTTPS y certificados para **múltiples dominios**, para múltiples aplicaciones, y luego transmitir los requests a la aplicación correcta en cada caso. |
|||
|
|||
### Renovación de Certificados |
|||
|
|||
En algún momento en el futuro, cada certificado **expiraría** (alrededor de 3 meses después de haberlo adquirido). |
|||
|
|||
Y entonces, habría otro programa (en algunos casos es otro programa, en algunos casos podría ser el mismo TLS Termination Proxy) que hablaría con Let's Encrypt y renovaría el/los certificado(s). |
|||
|
|||
<img src="/img/deployment/https/https.svg"> |
|||
|
|||
Los **certificados TLS** están **asociados con un nombre de dominio**, no con una dirección IP. |
|||
|
|||
Entonces, para renovar los certificados, el programa de renovación necesita **probar** a la autoridad (Let's Encrypt) que de hecho **"posee" y controla ese dominio**. |
|||
|
|||
Para hacer eso, y para acomodar diferentes necesidades de aplicaciones, hay varias formas en que puede hacerlo. Algunas formas populares son: |
|||
|
|||
* **Modificar algunos registros DNS**. |
|||
* Para esto, el programa de renovación necesita soportar las API del proveedor de DNS, por lo que, dependiendo del proveedor de DNS que estés utilizando, esto podría o no ser una opción. |
|||
* **Ejecutarse como un servidor** (al menos durante el proceso de adquisición del certificado) en la dirección IP pública asociada con el dominio. |
|||
* Como dijimos anteriormente, solo un proceso puede estar escuchando en una IP y puerto específicos. |
|||
* Esta es una de las razones por las que es muy útil cuando el mismo TLS Termination Proxy también se encarga del proceso de renovación del certificado. |
|||
* De lo contrario, podrías tener que detener momentáneamente el TLS Termination Proxy, iniciar el programa de renovación para adquirir los certificados, luego configurarlos con el TLS Termination Proxy, y luego reiniciar el TLS Termination Proxy. Esto no es ideal, ya que tus aplicaciones no estarán disponibles durante el tiempo que el TLS Termination Proxy esté apagado. |
|||
|
|||
Todo este proceso de renovación, mientras aún se sirve la aplicación, es una de las principales razones por las que querrías tener un **sistema separado para gestionar el HTTPS** con un TLS Termination Proxy en lugar de simplemente usar los certificados TLS con el servidor de aplicaciones directamente (por ejemplo, Uvicorn). |
|||
|
|||
## Resumen |
|||
|
|||
Tener **HTTPS** es muy importante y bastante **crítico** en la mayoría de los casos. La mayor parte del esfuerzo que como desarrollador tienes que poner en torno a HTTPS es solo sobre **entender estos conceptos** y cómo funcionan. |
|||
|
|||
Pero una vez que conoces la información básica de **HTTPS para desarrolladores** puedes combinar y configurar fácilmente diferentes herramientas para ayudarte a gestionar todo de una manera sencilla. |
|||
|
|||
En algunos de los siguientes capítulos, te mostraré varios ejemplos concretos de cómo configurar **HTTPS** para aplicaciones **FastAPI**. 🔒 |
@ -1,21 +1,21 @@ |
|||
# Despliegue - Introducción |
|||
# Despliegue |
|||
|
|||
Desplegar una aplicación hecha con **FastAPI** es relativamente fácil. |
|||
Desplegar una aplicación **FastAPI** es relativamente fácil. |
|||
|
|||
## ¿Qué significa desplegar una aplicación? |
|||
## Qué Significa Despliegue |
|||
|
|||
**Desplegar** una aplicación significa realizar una serie de pasos para hacerla **disponible para los usuarios**. |
|||
**Desplegar** una aplicación significa realizar los pasos necesarios para hacerla **disponible para los usuarios**. |
|||
|
|||
Para una **API web**, normalmente implica ponerla en una **máquina remota**, con un **programa de servidor** que proporcione un buen rendimiento, estabilidad, etc, para que sus **usuarios** puedan **acceder** a la aplicación de manera eficiente y sin interrupciones o problemas. |
|||
Para una **API web**, normalmente implica ponerla en una **máquina remota**, con un **programa de servidor** que proporcione buen rendimiento, estabilidad, etc., para que tus **usuarios** puedan **acceder** a la aplicación de manera eficiente y sin interrupciones o problemas. |
|||
|
|||
Esto difiere en las fases de **desarrollo**, donde estás constantemente cambiando el código, rompiéndolo y arreglándolo, deteniendo y reiniciando el servidor de desarrollo, etc. |
|||
Esto contrasta con las etapas de **desarrollo**, donde estás constantemente cambiando el código, rompiéndolo y arreglándolo, deteniendo y reiniciando el servidor de desarrollo, etc. |
|||
|
|||
## Estrategias de despliegue |
|||
## Estrategias de Despliegue |
|||
|
|||
Existen varias formas de hacerlo dependiendo de tu caso de uso específico y las herramientas que uses. |
|||
Hay varias maneras de hacerlo dependiendo de tu caso de uso específico y las herramientas que utilices. |
|||
|
|||
Puedes **desplegar un servidor** tú mismo usando un conjunto de herramientas, puedes usar **servicios en la nube** que haga parte del trabajo por ti, o usar otras posibles opciones. |
|||
Podrías **desplegar un servidor** tú mismo utilizando una combinación de herramientas, podrías usar un **servicio en la nube** que hace parte del trabajo por ti, u otras opciones posibles. |
|||
|
|||
Te enseñaré algunos de los conceptos principales que debes tener en cuenta al desplegar aplicaciones hechas con **FastAPI** (aunque la mayoría de estos conceptos aplican para cualquier otro tipo de aplicación web). |
|||
Te mostraré algunos de los conceptos principales que probablemente deberías tener en cuenta al desplegar una aplicación **FastAPI** (aunque la mayoría se aplica a cualquier otro tipo de aplicación web). |
|||
|
|||
Podrás ver más detalles para tener en cuenta y algunas de las técnicas para hacerlo en las próximas secciones.✨ |
|||
Verás más detalles a tener en cuenta y algunas de las técnicas para hacerlo en las siguientes secciones. ✨ |
|||
|
@ -0,0 +1,169 @@ |
|||
# Ejecutar un Servidor Manualmente |
|||
|
|||
## Usa el Comando `fastapi run` |
|||
|
|||
En resumen, usa `fastapi run` para servir tu aplicación FastAPI: |
|||
|
|||
<div class="termy"> |
|||
|
|||
```console |
|||
$ <font color="#4E9A06">fastapi</font> run <u style="text-decoration-style:single">main.py</u> |
|||
<font color="#3465A4">INFO </font> Usando path <font color="#3465A4">main.py</font> |
|||
<font color="#3465A4">INFO </font> Path absoluto resuelto <font color="#75507B">/home/user/code/awesomeapp/</font><font color="#AD7FA8">main.py</font> |
|||
<font color="#3465A4">INFO </font> Buscando una estructura de archivos de paquete desde directorios con archivos <font color="#3465A4">__init__.py</font> |
|||
<font color="#3465A4">INFO </font> Importando desde <font color="#75507B">/home/user/code/</font><font color="#AD7FA8">awesomeapp</font> |
|||
|
|||
╭─ <font color="#8AE234"><b>Archivo de módulo de Python</b></font> ─╮ |
|||
│ │ |
|||
│ 🐍 main.py │ |
|||
│ │ |
|||
╰──────────────────────╯ |
|||
|
|||
<font color="#3465A4">INFO </font> Importando módulo <font color="#4E9A06">main</font> |
|||
<font color="#3465A4">INFO </font> Encontrada aplicación FastAPI importable |
|||
|
|||
╭─ <font color="#8AE234"><b>Aplicación FastAPI importable</b></font> ─╮ |
|||
│ │ |
|||
│ <span style="background-color:#272822"><font color="#FF4689">from</font></span><span style="background-color:#272822"><font color="#F8F8F2"> main </font></span><span style="background-color:#272822"><font color="#FF4689">import</font></span><span style="background-color:#272822"><font color="#F8F8F2"> app</font></span><span style="background-color:#272822"> </span> │ |
|||
│ │ |
|||
╰──────────────────────────╯ |
|||
|
|||
<font color="#3465A4">INFO </font> Usando la cadena de import <font color="#8AE234"><b>main:app</b></font> |
|||
|
|||
<font color="#4E9A06">╭─────────── CLI de FastAPI - Modo Producción ───────────╮</font> |
|||
<font color="#4E9A06">│ │</font> |
|||
<font color="#4E9A06">│ Sirviendo en: http://0.0.0.0:8000 │</font> |
|||
<font color="#4E9A06">│ │</font> |
|||
<font color="#4E9A06">│ Docs de API: http://0.0.0.0:8000/docs │</font> |
|||
<font color="#4E9A06">│ │</font> |
|||
<font color="#4E9A06">│ Corriendo en modo producción, para desarrollo usa: │</font> |
|||
<font color="#4E9A06">│ │</font> |
|||
<font color="#4E9A06">│ </font><font color="#8AE234"><b>fastapi dev</b></font><font color="#4E9A06"> │</font> |
|||
<font color="#4E9A06">│ │</font> |
|||
<font color="#4E9A06">╰─────────────────────────────────────────────────────╯</font> |
|||
|
|||
<font color="#4E9A06">INFO</font>: Iniciado el proceso del servidor [<font color="#06989A">2306215</font>] |
|||
<font color="#4E9A06">INFO</font>: Esperando el inicio de la aplicación. |
|||
<font color="#4E9A06">INFO</font>: Inicio de la aplicación completado. |
|||
<font color="#4E9A06">INFO</font>: Uvicorn corriendo en <b>http://0.0.0.0:8000</b> (Presiona CTRL+C para salir) |
|||
``` |
|||
|
|||
</div> |
|||
|
|||
Eso funcionaría para la mayoría de los casos. 😎 |
|||
|
|||
Podrías usar ese comando, por ejemplo, para iniciar tu app **FastAPI** en un contenedor, en un servidor, etc. |
|||
|
|||
## Servidores ASGI |
|||
|
|||
Vamos a profundizar un poquito en los detalles. |
|||
|
|||
FastAPI usa un estándar para construir frameworks de web y servidores de Python llamado <abbr title="Asynchronous Server Gateway Interface">ASGI</abbr>. FastAPI es un framework web ASGI. |
|||
|
|||
Lo principal que necesitas para ejecutar una aplicación **FastAPI** (o cualquier otra aplicación ASGI) en una máquina de servidor remota es un programa de servidor ASGI como **Uvicorn**, que es el que viene por defecto en el comando `fastapi`. |
|||
|
|||
Hay varias alternativas, incluyendo: |
|||
|
|||
* <a href="https://www.uvicorn.org/" class="external-link" target="_blank">Uvicorn</a>: un servidor ASGI de alto rendimiento. |
|||
* <a href="https://hypercorn.readthedocs.io/" class="external-link" target="_blank">Hypercorn</a>: un servidor ASGI compatible con HTTP/2 y Trio entre otras funcionalidades. |
|||
* <a href="https://github.com/django/daphne" class="external-link" target="_blank">Daphne</a>: el servidor ASGI construido para Django Channels. |
|||
* <a href="https://github.com/emmett-framework/granian" class="external-link" target="_blank">Granian</a>: Un servidor HTTP Rust para aplicaciones en Python. |
|||
* <a href="https://unit.nginx.org/howto/fastapi/" class="external-link" target="_blank">NGINX Unit</a>: NGINX Unit es un runtime para aplicaciones web ligero y versátil. |
|||
|
|||
## Máquina Servidor y Programa Servidor |
|||
|
|||
Hay un pequeño detalle sobre los nombres que hay que tener en cuenta. 💡 |
|||
|
|||
La palabra "**servidor**" se utiliza comúnmente para referirse tanto al computador remoto/en la nube (la máquina física o virtual) como al programa que se está ejecutando en esa máquina (por ejemplo, Uvicorn). |
|||
|
|||
Solo ten en cuenta que cuando leas "servidor" en general, podría referirse a una de esas dos cosas. |
|||
|
|||
Al referirse a la máquina remota, es común llamarla **servidor**, pero también **máquina**, **VM** (máquina virtual), **nodo**. Todos esos se refieren a algún tipo de máquina remota, generalmente con Linux, donde ejecutas programas. |
|||
|
|||
## Instala el Programa del Servidor |
|||
|
|||
Cuando instalas FastAPI, viene con un servidor de producción, Uvicorn, y puedes iniciarlo con el comando `fastapi run`. |
|||
|
|||
Pero también puedes instalar un servidor ASGI manualmente. |
|||
|
|||
Asegúrate de crear un [entorno virtual](../virtual-environments.md){.internal-link target=_blank}, actívalo, y luego puedes instalar la aplicación del servidor. |
|||
|
|||
Por ejemplo, para instalar Uvicorn: |
|||
|
|||
<div class="termy"> |
|||
|
|||
```console |
|||
$ pip install "uvicorn[standard]" |
|||
|
|||
---> 100% |
|||
``` |
|||
|
|||
</div> |
|||
|
|||
Un proceso similar se aplicaría a cualquier otro programa de servidor ASGI. |
|||
|
|||
/// tip | Consejo |
|||
|
|||
Al añadir `standard`, Uvicorn instalará y usará algunas dependencias adicionales recomendadas. |
|||
|
|||
Eso incluye `uvloop`, el reemplazo de alto rendimiento para `asyncio`, que proporciona un gran impulso de rendimiento en concurrencia. |
|||
|
|||
Cuando instalas FastAPI con algo como `pip install "fastapi[standard]"` ya obtienes `uvicorn[standard]` también. |
|||
|
|||
/// |
|||
|
|||
## Ejecuta el Programa del Servidor |
|||
|
|||
Si instalaste un servidor ASGI manualmente, normalmente necesitarías pasar una cadena de import en un formato especial para que importe tu aplicación FastAPI: |
|||
|
|||
<div class="termy"> |
|||
|
|||
```console |
|||
$ uvicorn main:app --host 0.0.0.0 --port 80 |
|||
|
|||
<span style="color: green;">INFO</span>: Uvicorn corriendo en http://0.0.0.0:80 (Presiona CTRL+C para salir) |
|||
``` |
|||
|
|||
</div> |
|||
|
|||
/// note | Nota |
|||
|
|||
El comando `uvicorn main:app` se refiere a: |
|||
|
|||
* `main`: el archivo `main.py` (el "módulo" de Python). |
|||
* `app`: el objeto creado dentro de `main.py` con la línea `app = FastAPI()`. |
|||
|
|||
Es equivalente a: |
|||
|
|||
```Python |
|||
from main import app |
|||
``` |
|||
|
|||
/// |
|||
|
|||
Cada programa alternativo de servidor ASGI tendría un comando similar, puedes leer más en su respectiva documentación. |
|||
|
|||
/// warning | Advertencia |
|||
|
|||
Uvicorn y otros servidores soportan una opción `--reload` que es útil durante el desarrollo. |
|||
|
|||
La opción `--reload` consume muchos más recursos, es más inestable, etc. |
|||
|
|||
Ayuda mucho durante el **desarrollo**, pero **no** deberías usarla en **producción**. |
|||
|
|||
/// |
|||
|
|||
## Conceptos de Despliegue |
|||
|
|||
Estos ejemplos ejecutan el programa del servidor (por ejemplo, Uvicorn), iniciando **un solo proceso**, escuchando en todas las IPs (`0.0.0.0`) en un puerto predefinido (por ejemplo, `80`). |
|||
|
|||
Esta es la idea básica. Pero probablemente querrás encargarte de algunas cosas adicionales, como: |
|||
|
|||
* Seguridad - HTTPS |
|||
* Ejecución en el arranque |
|||
* Reinicios |
|||
* Replicación (el número de procesos ejecutándose) |
|||
* Memoria |
|||
* Pasos previos antes de comenzar |
|||
|
|||
Te contaré más sobre cada uno de estos conceptos, cómo pensarlos, y algunos ejemplos concretos con estrategias para manejarlos en los próximos capítulos. 🚀 |
@ -0,0 +1,152 @@ |
|||
# Servidores Workers - Uvicorn con Workers |
|||
|
|||
Vamos a revisar esos conceptos de despliegue de antes: |
|||
|
|||
* Seguridad - HTTPS |
|||
* Ejecución al inicio |
|||
* Reinicios |
|||
* **Replicación (el número de procesos en ejecución)** |
|||
* Memoria |
|||
* Pasos previos antes de empezar |
|||
|
|||
Hasta este punto, con todos los tutoriales en la documentación, probablemente has estado ejecutando un **programa de servidor**, por ejemplo, usando el comando `fastapi`, que ejecuta Uvicorn, corriendo un **solo proceso**. |
|||
|
|||
Al desplegar aplicaciones probablemente querrás tener algo de **replicación de procesos** para aprovechar **múltiples núcleos** y poder manejar más requests. |
|||
|
|||
Como viste en el capítulo anterior sobre [Conceptos de Despliegue](concepts.md){.internal-link target=_blank}, hay múltiples estrategias que puedes usar. |
|||
|
|||
Aquí te mostraré cómo usar **Uvicorn** con **worker processes** usando el comando `fastapi` o el comando `uvicorn` directamente. |
|||
|
|||
/// info | Información |
|||
|
|||
Si estás usando contenedores, por ejemplo con Docker o Kubernetes, te contaré más sobre eso en el próximo capítulo: [FastAPI en Contenedores - Docker](docker.md){.internal-link target=_blank}. |
|||
|
|||
En particular, cuando corras en **Kubernetes** probablemente **no** querrás usar workers y en cambio correr **un solo proceso de Uvicorn por contenedor**, pero te contaré sobre eso más adelante en ese capítulo. |
|||
|
|||
/// |
|||
|
|||
## Múltiples Workers |
|||
|
|||
Puedes iniciar múltiples workers con la opción de línea de comando `--workers`: |
|||
|
|||
//// tab | `fastapi` |
|||
|
|||
Si usas el comando `fastapi`: |
|||
|
|||
<div class="termy"> |
|||
|
|||
```console |
|||
$ <pre> <font color="#4E9A06">fastapi</font> run --workers 4 <u style="text-decoration-style:single">main.py</u> |
|||
<font color="#3465A4">INFO </font> Using path <font color="#3465A4">main.py</font> |
|||
<font color="#3465A4">INFO </font> Resolved absolute path <font color="#75507B">/home/user/code/awesomeapp/</font><font color="#AD7FA8">main.py</font> |
|||
<font color="#3465A4">INFO </font> Searching for package file structure from directories with <font color="#3465A4">__init__.py</font> files |
|||
<font color="#3465A4">INFO </font> Importing from <font color="#75507B">/home/user/code/</font><font color="#AD7FA8">awesomeapp</font> |
|||
|
|||
╭─ <font color="#8AE234"><b>Python module file</b></font> ─╮ |
|||
│ │ |
|||
│ 🐍 main.py │ |
|||
│ │ |
|||
╰──────────────────────╯ |
|||
|
|||
<font color="#3465A4">INFO </font> Importing module <font color="#4E9A06">main</font> |
|||
<font color="#3465A4">INFO </font> Found importable FastAPI app |
|||
|
|||
╭─ <font color="#8AE234"><b>Importable FastAPI app</b></font> ─╮ |
|||
│ │ |
|||
│ <span style="background-color:#272822"><font color="#FF4689">from</font></span><span style="background-color:#272822"><font color="#F8F8F2"> main </font></span><span style="background-color:#272822"><font color="#FF4689">import</font></span><span style="background-color:#272822"><font color="#F8F8F2"> app</font></span><span style="background-color:#272822"> </span> │ |
|||
│ │ |
|||
╰──────────────────────────╯ |
|||
|
|||
<font color="#3465A4">INFO </font> Using import string <font color="#8AE234"><b>main:app</b></font> |
|||
|
|||
<font color="#4E9A06">╭─────────── FastAPI CLI - Production mode ───────────╮</font> |
|||
<font color="#4E9A06">│ │</font> |
|||
<font color="#4E9A06">│ Serving at: http://0.0.0.0:8000 │</font> |
|||
<font color="#4E9A06">│ │</font> |
|||
<font color="#4E9A06">│ API docs: http://0.0.0.0:8000/docs │</font> |
|||
<font color="#4E9A06">│ │</font> |
|||
<font color="#4E9A06">│ Running in production mode, for development use: │</font> |
|||
<font color="#4E9A06">│ │</font> |
|||
<font color="#4E9A06">│ </font><font color="#8AE234"><b>fastapi dev</b></font><font color="#4E9A06"> │</font> |
|||
<font color="#4E9A06">│ │</font> |
|||
<font color="#4E9A06">╰─────────────────────────────────────────────────────╯</font> |
|||
|
|||
<font color="#4E9A06">INFO</font>: Uvicorn running on <b>http://0.0.0.0:8000</b> (Press CTRL+C to quit) |
|||
<font color="#4E9A06">INFO</font>: Started parent process [<font color="#34E2E2"><b>27365</b></font>] |
|||
<font color="#4E9A06">INFO</font>: Started server process [<font color="#06989A">27368</font>] |
|||
<font color="#4E9A06">INFO</font>: Waiting for application startup. |
|||
<font color="#4E9A06">INFO</font>: Application startup complete. |
|||
<font color="#4E9A06">INFO</font>: Started server process [<font color="#06989A">27369</font>] |
|||
<font color="#4E9A06">INFO</font>: Waiting for application startup. |
|||
<font color="#4E9A06">INFO</font>: Application startup complete. |
|||
<font color="#4E9A06">INFO</font>: Started server process [<font color="#06989A">27370</font>] |
|||
<font color="#4E9A06">INFO</font>: Waiting for application startup. |
|||
<font color="#4E9A06">INFO</font>: Application startup complete. |
|||
<font color="#4E9A06">INFO</font>: Started server process [<font color="#06989A">27367</font>] |
|||
<font color="#4E9A06">INFO</font>: Waiting for application startup. |
|||
<font color="#4E9A06">INFO</font>: Application startup complete. |
|||
</pre> |
|||
``` |
|||
|
|||
</div> |
|||
|
|||
//// |
|||
|
|||
//// tab | `uvicorn` |
|||
|
|||
Si prefieres usar el comando `uvicorn` directamente: |
|||
|
|||
<div class="termy"> |
|||
|
|||
```console |
|||
$ uvicorn main:app --host 0.0.0.0 --port 8080 --workers 4 |
|||
<font color="#A6E22E">INFO</font>: Uvicorn running on <b>http://0.0.0.0:8080</b> (Press CTRL+C to quit) |
|||
<font color="#A6E22E">INFO</font>: Started parent process [<font color="#A1EFE4"><b>27365</b></font>] |
|||
<font color="#A6E22E">INFO</font>: Started server process [<font color="#A1EFE4">27368</font>] |
|||
<font color="#A6E22E">INFO</font>: Waiting for application startup. |
|||
<font color="#A6E22E">INFO</font>: Application startup complete. |
|||
<font color="#A6E22E">INFO</font>: Started server process [<font color="#A1EFE4">27369</font>] |
|||
<font color="#A6E22E">INFO</font>: Waiting for application startup. |
|||
<font color="#A6E22E">INFO</font>: Application startup complete. |
|||
<font color="#A6E22E">INFO</font>: Started server process [<font color="#A1EFE4">27370</font>] |
|||
<font color="#A6E22E">INFO</font>: Waiting for application startup. |
|||
<font color="#A6E22E">INFO</font>: Application startup complete. |
|||
<font color="#A6E22E">INFO</font>: Started server process [<font color="#A1EFE4">27367</font>] |
|||
<font color="#A6E22E">INFO</font>: Waiting for application startup. |
|||
<font color="#A6E22E">INFO</font>: Application startup complete. |
|||
``` |
|||
|
|||
</div> |
|||
|
|||
//// |
|||
|
|||
La única opción nueva aquí es `--workers` indicando a Uvicorn que inicie 4 worker processes. |
|||
|
|||
También puedes ver que muestra el **PID** de cada proceso, `27365` para el proceso padre (este es el **gestor de procesos**) y uno para cada worker process: `27368`, `27369`, `27370`, y `27367`. |
|||
|
|||
## Conceptos de Despliegue |
|||
|
|||
Aquí viste cómo usar múltiples **workers** para **paralelizar** la ejecución de la aplicación, aprovechar los **múltiples núcleos** del CPU, y poder servir **más requests**. |
|||
|
|||
De la lista de conceptos de despliegue de antes, usar workers ayudaría principalmente con la parte de **replicación**, y un poquito con los **reinicios**, pero aún necesitas encargarte de los otros: |
|||
|
|||
* **Seguridad - HTTPS** |
|||
* **Ejecución al inicio** |
|||
* ***Reinicios*** |
|||
* Replicación (el número de procesos en ejecución) |
|||
* **Memoria** |
|||
* **Pasos previos antes de empezar** |
|||
|
|||
## Contenedores y Docker |
|||
|
|||
En el próximo capítulo sobre [FastAPI en Contenedores - Docker](docker.md){.internal-link target=_blank} te explicaré algunas estrategias que podrías usar para manejar los otros **conceptos de despliegue**. |
|||
|
|||
Te mostraré cómo **construir tu propia imagen desde cero** para ejecutar un solo proceso de Uvicorn. Es un proceso sencillo y probablemente es lo que querrías hacer al usar un sistema de gestión de contenedores distribuido como **Kubernetes**. |
|||
|
|||
## Resumen |
|||
|
|||
Puedes usar múltiples worker processes con la opción CLI `--workers` con los comandos `fastapi` o `uvicorn` para aprovechar los **CPUs de múltiples núcleos**, para ejecutar **múltiples procesos en paralelo**. |
|||
|
|||
Podrías usar estas herramientas e ideas si estás instalando **tu propio sistema de despliegue** mientras te encargas tú mismo de los otros conceptos de despliegue. |
|||
|
|||
Revisa el próximo capítulo para aprender sobre **FastAPI** con contenedores (por ejemplo, Docker y Kubernetes). Verás que esas herramientas tienen formas sencillas de resolver los otros **conceptos de despliegue** también. ✨ |
@ -1,93 +1,93 @@ |
|||
# Acerca de las versiones de FastAPI |
|||
# Sobre las versiones de FastAPI |
|||
|
|||
**FastAPI** está siendo utilizado en producción en muchas aplicaciones y sistemas. La cobertura de los tests se mantiene al 100%. Sin embargo, su desarrollo sigue siendo rápido. |
|||
**FastAPI** ya se está utilizando en producción en muchas aplicaciones y sistemas. Y la cobertura de tests se mantiene al 100%. Pero su desarrollo sigue avanzando rápidamente. |
|||
|
|||
Se agregan nuevas características frecuentemente, se corrigen errores continuamente y el código está constantemente mejorando. |
|||
Se añaden nuevas funcionalidades con frecuencia, se corrigen bugs regularmente, y el código sigue mejorando continuamente. |
|||
|
|||
Por eso las versiones actuales siguen siendo `0.x.x`, esto significa que cada versión puede potencialmente tener <abbr title="cambios que rompen funcionalidades o compatibilidad">*breaking changes*</abbr>. Las versiones siguen las convenciones de <a href="https://semver.org/" class="external-link" target="_blank"><abbr title="versionado semántico">*Semantic Versioning*</abbr></a>. |
|||
Por eso las versiones actuales siguen siendo `0.x.x`, esto refleja que cada versión podría tener potencialmente cambios incompatibles. Esto sigue las convenciones de <a href="https://semver.org/" class="external-link" target="_blank">Semantic Versioning</a>. |
|||
|
|||
Puedes crear aplicaciones listas para producción con **FastAPI** ahora mismo (y probablemente lo has estado haciendo por algún tiempo), solo tienes que asegurarte de usar la versión que funciona correctamente con el resto de tu código. |
|||
Puedes crear aplicaciones de producción con **FastAPI** ahora mismo (y probablemente ya lo has estado haciendo desde hace algún tiempo), solo debes asegurarte de que utilizas una versión que funciona correctamente con el resto de tu código. |
|||
|
|||
## Fijar la versión de `fastapi` |
|||
## Fijar tu versión de `fastapi` |
|||
|
|||
Lo primero que debes hacer en tu proyecto es "fijar" la última versión específica de **FastAPI** que sabes que funciona bien con tu aplicación. |
|||
Lo primero que debes hacer es "fijar" la versión de **FastAPI** que estás usando a la versión específica más reciente que sabes que funciona correctamente para tu aplicación. |
|||
|
|||
Por ejemplo, digamos que estás usando la versión `0.45.0` en tu aplicación. |
|||
Por ejemplo, digamos que estás utilizando la versión `0.112.0` en tu aplicación. |
|||
|
|||
Si usas el archivo `requirements.txt` puedes especificar la versión con: |
|||
Si usas un archivo `requirements.txt` podrías especificar la versión con: |
|||
|
|||
```txt |
|||
fastapi==0.45.0 |
|||
fastapi[standard]==0.112.0 |
|||
``` |
|||
|
|||
esto significa que usarás específicamente la versión `0.45.0`. |
|||
eso significaría que usarías exactamente la versión `0.112.0`. |
|||
|
|||
También puedes fijar las versiones de esta forma: |
|||
O también podrías fijarla con: |
|||
|
|||
```txt |
|||
fastapi>=0.45.0,<0.46.0 |
|||
fastapi[standard]>=0.112.0,<0.113.0 |
|||
``` |
|||
|
|||
esto significa que usarás la versión `0.45.0` o superiores, pero menores a la versión `0.46.0`, por ejemplo, la versión `0.45.2` sería aceptada. |
|||
eso significaría que usarías las versiones `0.112.0` o superiores, pero menores que `0.113.0`, por ejemplo, una versión `0.112.2` todavía sería aceptada. |
|||
|
|||
Si usas cualquier otra herramienta para manejar tus instalaciones, como Poetry, Pipenv, u otras, todas tienen una forma que puedes usar para definir versiones específicas para tus paquetes. |
|||
Si utilizas cualquier otra herramienta para gestionar tus instalaciones, como `uv`, Poetry, Pipenv, u otras, todas tienen una forma que puedes usar para definir versiones específicas para tus paquetes. |
|||
|
|||
## Versiones disponibles |
|||
|
|||
Puedes ver las versiones disponibles (por ejemplo, para revisar cuál es la actual) en las [Release Notes](../release-notes.md){.internal-link target=_blank}. |
|||
Puedes ver las versiones disponibles (por ejemplo, para revisar cuál es la más reciente) en las [Release Notes](../release-notes.md){.internal-link target=_blank}. |
|||
|
|||
## Acerca de las versiones |
|||
## Sobre las versiones |
|||
|
|||
Siguiendo las convenciones de *Semantic Versioning*, cualquier versión por debajo de `1.0.0` puede potencialmente tener <abbr title="cambios que rompen funcionalidades o compatibilidad">*breaking changes*</abbr>. |
|||
Siguiendo las convenciones del Semantic Versioning, cualquier versión por debajo de `1.0.0` podría potencialmente añadir cambios incompatibles. |
|||
|
|||
FastAPI también sigue la convención de que cualquier cambio hecho en una <abbr title="versiones de parche">"PATCH" version</abbr> es para solucionar errores y <abbr title="cambios que no rompan funcionalidades o compatibilidad">*non-breaking changes*</abbr>. |
|||
FastAPI también sigue la convención de que cualquier cambio de versión "PATCH" es para corrección de bugs y cambios no incompatibles. |
|||
|
|||
/// tip | Consejo |
|||
|
|||
El <abbr title="parche">"PATCH"</abbr> es el último número, por ejemplo, en `0.2.3`, la <abbr title="versiones de parche">PATCH version</abbr> es `3`. |
|||
El "PATCH" es el último número, por ejemplo, en `0.2.3`, la versión PATCH es `3`. |
|||
|
|||
/// |
|||
|
|||
Entonces, deberías fijar la versión así: |
|||
Así que deberías poder fijar a una versión como: |
|||
|
|||
```txt |
|||
fastapi>=0.45.0,<0.46.0 |
|||
``` |
|||
|
|||
En versiones <abbr title="versiones menores">"MINOR"</abbr> son añadidas nuevas características y posibles <abbr title="Cambios que rompen posibles funcionalidades o compatibilidad">breaking changes</abbr>. |
|||
Los cambios incompatibles y nuevas funcionalidades se añaden en versiones "MINOR". |
|||
|
|||
/// tip | Consejo |
|||
|
|||
La versión "MINOR" es el número en el medio, por ejemplo, en `0.2.3`, la <abbr title="versión menor">"MINOR" version</abbr> es `2`. |
|||
El "MINOR" es el número en el medio, por ejemplo, en `0.2.3`, la versión MINOR es `2`. |
|||
|
|||
/// |
|||
|
|||
## Actualizando las versiones de FastAPI |
|||
|
|||
Para esto es recomendable primero añadir tests a tu aplicación. |
|||
Deberías añadir tests para tu aplicación. |
|||
|
|||
Con **FastAPI** es muy fácil (gracias a Starlette), revisa la documentación [Testing](../tutorial/testing.md){.internal-link target=_blank} |
|||
Con **FastAPI** es muy fácil (gracias a Starlette), revisa la documentación: [Testing](../tutorial/testing.md){.internal-link target=_blank} |
|||
|
|||
Luego de tener los tests, puedes actualizar la versión de **FastAPI** a una más reciente y asegurarte de que tu código funciona correctamente ejecutando los tests. |
|||
Después de tener tests, puedes actualizar la versión de **FastAPI** a una más reciente, y asegurarte de que todo tu código está funcionando correctamente ejecutando tus tests. |
|||
|
|||
Si todo funciona correctamente, o haces los cambios necesarios para que esto suceda, y todos tus tests pasan, entonces puedes fijar tu versión de `fastapi` a la más reciente. |
|||
Si todo está funcionando, o después de hacer los cambios necesarios, y todos tus tests pasan, entonces puedes fijar tu `fastapi` a esa nueva versión más reciente. |
|||
|
|||
## Acerca de Starlette |
|||
## Sobre Starlette |
|||
|
|||
No deberías fijar la versión de `starlette`. |
|||
|
|||
Diferentes versiones de **FastAPI** pueden usar una versión específica de Starlette. |
|||
Diferentes versiones de **FastAPI** utilizarán una versión más reciente específica de Starlette. |
|||
|
|||
Entonces, puedes dejar que **FastAPI** se asegure por sí mismo de qué versión de Starlette usar. |
|||
Así que, puedes simplemente dejar que **FastAPI** use la versión correcta de Starlette. |
|||
|
|||
## Acerca de Pydantic |
|||
## Sobre Pydantic |
|||
|
|||
Pydantic incluye los tests para **FastAPI** dentro de sus propios tests, esto significa que las versiones de Pydantic (superiores a `1.0.0`) son compatibles con FastAPI. |
|||
Pydantic incluye los tests para **FastAPI** con sus propios tests, así que nuevas versiones de Pydantic (por encima de `1.0.0`) siempre son compatibles con FastAPI. |
|||
|
|||
Puedes fijar Pydantic a cualquier versión superior a `1.0.0` e inferior a `2.0.0` que funcione para ti. |
|||
Puedes fijar Pydantic a cualquier versión por encima de `1.0.0` que funcione para ti. |
|||
|
|||
Por ejemplo: |
|||
|
|||
```txt |
|||
pydantic>=1.2.0,<2.0.0 |
|||
pydantic>=2.7.0,<3.0.0 |
|||
``` |
|||
|
@ -0,0 +1,298 @@ |
|||
# Variables de Entorno |
|||
|
|||
/// tip | Consejo |
|||
|
|||
Si ya sabes qué son las "variables de entorno" y cómo usarlas, siéntete libre de saltarte esto. |
|||
|
|||
/// |
|||
|
|||
Una variable de entorno (también conocida como "**env var**") es una variable que vive **fuera** del código de Python, en el **sistema operativo**, y podría ser leída por tu código de Python (o por otros programas también). |
|||
|
|||
Las variables de entorno pueden ser útiles para manejar **configuraciones** de aplicaciones, como parte de la **instalación** de Python, etc. |
|||
|
|||
## Crear y Usar Variables de Entorno |
|||
|
|||
Puedes **crear** y usar variables de entorno en la **shell (terminal)**, sin necesidad de Python: |
|||
|
|||
//// tab | Linux, macOS, Windows Bash |
|||
|
|||
<div class="termy"> |
|||
|
|||
```console |
|||
// Podrías crear una env var MY_NAME con |
|||
$ export MY_NAME="Wade Wilson" |
|||
|
|||
// Luego podrías usarla con otros programas, como |
|||
$ echo "Hello $MY_NAME" |
|||
|
|||
Hello Wade Wilson |
|||
``` |
|||
|
|||
</div> |
|||
|
|||
//// |
|||
|
|||
//// tab | Windows PowerShell |
|||
|
|||
<div class="termy"> |
|||
|
|||
```console |
|||
// Crea una env var MY_NAME |
|||
$ $Env:MY_NAME = "Wade Wilson" |
|||
|
|||
// Úsala con otros programas, como |
|||
$ echo "Hello $Env:MY_NAME" |
|||
|
|||
Hello Wade Wilson |
|||
``` |
|||
|
|||
</div> |
|||
|
|||
//// |
|||
|
|||
## Leer Variables de Entorno en Python |
|||
|
|||
También podrías crear variables de entorno **fuera** de Python, en la terminal (o con cualquier otro método), y luego **leerlas en Python**. |
|||
|
|||
Por ejemplo, podrías tener un archivo `main.py` con: |
|||
|
|||
```Python hl_lines="3" |
|||
import os |
|||
|
|||
name = os.getenv("MY_NAME", "World") |
|||
print(f"Hello {name} from Python") |
|||
``` |
|||
|
|||
/// tip | Consejo |
|||
|
|||
El segundo argumento de <a href="https://docs.python.org/3.8/library/os.html#os.getenv" class="external-link" target="_blank">`os.getenv()`</a> es el valor por defecto a retornar. |
|||
|
|||
Si no se proporciona, es `None` por defecto; aquí proporcionamos `"World"` como el valor por defecto para usar. |
|||
|
|||
/// |
|||
|
|||
Luego podrías llamar a ese programa Python: |
|||
|
|||
//// tab | Linux, macOS, Windows Bash |
|||
|
|||
<div class="termy"> |
|||
|
|||
```console |
|||
// Aquí todavía no configuramos la env var |
|||
$ python main.py |
|||
|
|||
// Como no configuramos la env var, obtenemos el valor por defecto |
|||
|
|||
Hello World from Python |
|||
|
|||
// Pero si creamos una variable de entorno primero |
|||
$ export MY_NAME="Wade Wilson" |
|||
|
|||
// Y luego llamamos al programa nuevamente |
|||
$ python main.py |
|||
|
|||
// Ahora puede leer la variable de entorno |
|||
|
|||
Hello Wade Wilson from Python |
|||
``` |
|||
|
|||
</div> |
|||
|
|||
//// |
|||
|
|||
//// tab | Windows PowerShell |
|||
|
|||
<div class="termy"> |
|||
|
|||
```console |
|||
// Aquí todavía no configuramos la env var |
|||
$ python main.py |
|||
|
|||
// Como no configuramos la env var, obtenemos el valor por defecto |
|||
|
|||
Hello World from Python |
|||
|
|||
// Pero si creamos una variable de entorno primero |
|||
$ $Env:MY_NAME = "Wade Wilson" |
|||
|
|||
// Y luego llamamos al programa nuevamente |
|||
$ python main.py |
|||
|
|||
// Ahora puede leer la variable de entorno |
|||
|
|||
Hello Wade Wilson from Python |
|||
``` |
|||
|
|||
</div> |
|||
|
|||
//// |
|||
|
|||
Dado que las variables de entorno pueden configurarse fuera del código, pero pueden ser leídas por el código, y no tienen que ser almacenadas (committed en `git`) con el resto de los archivos, es común usarlas para configuraciones o **ajustes**. |
|||
|
|||
También puedes crear una variable de entorno solo para una **invocación específica de un programa**, que está disponible solo para ese programa, y solo durante su duración. |
|||
|
|||
Para hacer eso, créala justo antes del programa en sí, en la misma línea: |
|||
|
|||
<div class="termy"> |
|||
|
|||
```console |
|||
// Crea una env var MY_NAME en línea para esta llamada del programa |
|||
$ MY_NAME="Wade Wilson" python main.py |
|||
|
|||
// Ahora puede leer la variable de entorno |
|||
|
|||
Hello Wade Wilson from Python |
|||
|
|||
// La env var ya no existe después |
|||
$ python main.py |
|||
|
|||
Hello World from Python |
|||
``` |
|||
|
|||
</div> |
|||
|
|||
/// tip | Consejo |
|||
|
|||
Puedes leer más al respecto en <a href="https://12factor.net/config" class="external-link" target="_blank">The Twelve-Factor App: Config</a>. |
|||
|
|||
/// |
|||
|
|||
## Tipos y Validación |
|||
|
|||
Estas variables de entorno solo pueden manejar **strings de texto**, ya que son externas a Python y deben ser compatibles con otros programas y el resto del sistema (e incluso con diferentes sistemas operativos, como Linux, Windows, macOS). |
|||
|
|||
Esto significa que **cualquier valor** leído en Python desde una variable de entorno **será un `str`**, y cualquier conversión a un tipo diferente o cualquier validación tiene que hacerse en el código. |
|||
|
|||
Aprenderás más sobre cómo usar variables de entorno para manejar **configuraciones de aplicación** en la [Guía del Usuario Avanzado - Ajustes y Variables de Entorno](./advanced/settings.md){.internal-link target=_blank}. |
|||
|
|||
## Variable de Entorno `PATH` |
|||
|
|||
Hay una variable de entorno **especial** llamada **`PATH`** que es utilizada por los sistemas operativos (Linux, macOS, Windows) para encontrar programas a ejecutar. |
|||
|
|||
El valor de la variable `PATH` es un string largo que consiste en directorios separados por dos puntos `:` en Linux y macOS, y por punto y coma `;` en Windows. |
|||
|
|||
Por ejemplo, la variable de entorno `PATH` podría verse así: |
|||
|
|||
//// tab | Linux, macOS |
|||
|
|||
```plaintext |
|||
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin |
|||
``` |
|||
|
|||
Esto significa que el sistema debería buscar programas en los directorios: |
|||
|
|||
* `/usr/local/bin` |
|||
* `/usr/bin` |
|||
* `/bin` |
|||
* `/usr/sbin` |
|||
* `/sbin` |
|||
|
|||
//// |
|||
|
|||
//// tab | Windows |
|||
|
|||
```plaintext |
|||
C:\Program Files\Python312\Scripts;C:\Program Files\Python312;C:\Windows\System32 |
|||
``` |
|||
|
|||
Esto significa que el sistema debería buscar programas en los directorios: |
|||
|
|||
* `C:\Program Files\Python312\Scripts` |
|||
* `C:\Program Files\Python312` |
|||
* `C:\Windows\System32` |
|||
|
|||
//// |
|||
|
|||
Cuando escribes un **comando** en la terminal, el sistema operativo **busca** el programa en **cada uno de esos directorios** listados en la variable de entorno `PATH`. |
|||
|
|||
Por ejemplo, cuando escribes `python` en la terminal, el sistema operativo busca un programa llamado `python` en el **primer directorio** de esa lista. |
|||
|
|||
Si lo encuentra, entonces lo **utilizará**. De lo contrario, continúa buscando en los **otros directorios**. |
|||
|
|||
### Instalando Python y Actualizando el `PATH` |
|||
|
|||
Cuando instalas Python, se te podría preguntar si deseas actualizar la variable de entorno `PATH`. |
|||
|
|||
//// tab | Linux, macOS |
|||
|
|||
Digamos que instalas Python y termina en un directorio `/opt/custompython/bin`. |
|||
|
|||
Si dices que sí para actualizar la variable de entorno `PATH`, entonces el instalador añadirá `/opt/custompython/bin` a la variable de entorno `PATH`. |
|||
|
|||
Podría verse así: |
|||
|
|||
```plaintext |
|||
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/custompython/bin |
|||
``` |
|||
|
|||
De esta manera, cuando escribes `python` en la terminal, el sistema encontrará el programa Python en `/opt/custompython/bin` (el último directorio) y usará ese. |
|||
|
|||
//// |
|||
|
|||
//// tab | Windows |
|||
|
|||
Digamos que instalas Python y termina en un directorio `C:\opt\custompython\bin`. |
|||
|
|||
Si dices que sí para actualizar la variable de entorno `PATH`, entonces el instalador añadirá `C:\opt\custompython\bin` a la variable de entorno `PATH`. |
|||
|
|||
```plaintext |
|||
C:\Program Files\Python312\Scripts;C:\Program Files\Python312;C:\Windows\System32;C:\opt\custompython\bin |
|||
``` |
|||
|
|||
De esta manera, cuando escribes `python` en la terminal, el sistema encontrará el programa Python en `C:\opt\custompython\bin` (el último directorio) y usará ese. |
|||
|
|||
//// |
|||
|
|||
Entonces, si escribes: |
|||
|
|||
<div class="termy"> |
|||
|
|||
```console |
|||
$ python |
|||
``` |
|||
|
|||
</div> |
|||
|
|||
//// tab | Linux, macOS |
|||
|
|||
El sistema **encontrará** el programa `python` en `/opt/custompython/bin` y lo ejecutará. |
|||
|
|||
Esto sería más o menos equivalente a escribir: |
|||
|
|||
<div class="termy"> |
|||
|
|||
```console |
|||
$ /opt/custompython/bin/python |
|||
``` |
|||
|
|||
</div> |
|||
|
|||
//// |
|||
|
|||
//// tab | Windows |
|||
|
|||
El sistema **encontrará** el programa `python` en `C:\opt\custompython\bin\python` y lo ejecutará. |
|||
|
|||
Esto sería más o menos equivalente a escribir: |
|||
|
|||
<div class="termy"> |
|||
|
|||
```console |
|||
$ C:\opt\custompython\bin\python |
|||
``` |
|||
|
|||
</div> |
|||
|
|||
//// |
|||
|
|||
Esta información será útil al aprender sobre [Entornos Virtuales](virtual-environments.md){.internal-link target=_blank}. |
|||
|
|||
## Conclusión |
|||
|
|||
Con esto deberías tener una comprensión básica de qué son las **variables de entorno** y cómo usarlas en Python. |
|||
|
|||
También puedes leer más sobre ellas en la <a href="https://en.wikipedia.org/wiki/Environment_variable" class="external-link" target="_blank">Wikipedia para Variable de Entorno</a>. |
|||
|
|||
En muchos casos no es muy obvio cómo las variables de entorno serían útiles y aplicables de inmediato. Pero siguen apareciendo en muchos escenarios diferentes cuando estás desarrollando, así que es bueno conocerlas. |
|||
|
|||
Por ejemplo, necesitarás esta información en la siguiente sección, sobre [Entornos Virtuales](virtual-environments.md). |