Você já colocou uma aplicação FastAPI + Vue.js em produção e percebeu que a performance não era bem o que os benchmarks prometiam?

Calma, não é culpa do framework. O FastAPI é rápido por construção, mas a velocidade some quando fazemos escolhas síncronas, esquecemos o cache ou deixamos o front-end carregar tudo de uma vez. Este guia é para quem quer ir além do básico e aplicar otimizações que realmente fazem diferença, sem rodeios. Vou te mostrar 5 estratégias — do event loop ao lazy loading — com código na mão e aquele “porquê” que ajuda a fixar o conceito.

O problema que quase todo mundo enfrenta

Rotas definidas com def (síncronas) são executadas em uma thread pool externa no FastAPI, mas, mesmo assim, para operações I/O puras (chamadas HTTP, leitura em disco, queries simples) elas acabam concorrendo de forma ineficiente. O resultado? Throughput menor e latência maior sob carga.

A solução na prática

Use async def sempre que a rota fizer operações de entrada/saída que possam ser aguardadas. O segredo está em todas as camadas serem assíncronas: biblioteca HTTP, driver do banco, cliente de cache.

from fastapi import FastAPI
import httpx

app = FastAPI()

@app.get("/dados-externos")
async def fetch_data():
    async with httpx.AsyncClient() as client:
        resposta = await client.get("https://api.externa.com/dados")
    return resposta.json()

Por que isso faz tanta diferença?

Enquanto a versão síncrona com requests bloqueia a thread inteira até a resposta chegar, a versão assíncrona libera o loop de eventos para processar outras requisições. Em um teste caseiro com 10 workers e chamadas a uma API externa (latência de ~200ms), observei um salto típico de 100 req/s para mais de 1500 req/s. O ganho é brutal em cenários I/O-bound.

Fique de olho:

Se dentro de uma rota async def você usar time.sleep() ou uma biblioteca bloqueante (ex.: requests.get), você anula todo o benefício. Mantenha o ecossistema async — e monitore com ferramentas como py-spy para achar gargalos silenciosos.

O cenário clássico

Consultas repetidas ao banco para dados que mudam pouco (catálogo de produtos, configurações, resultados de análises) geram latência desnecessária e pressionam o banco de dados. A resposta é tão simples quanto poderosa: uma camada de cache.

Implementação direto ao ponto

Aqui usamos o Redis com o cliente redis-py (modo async). A ideia é verificar o cache antes de bater no banco e, se não existir, popular o cache após a consulta.

from fastapi import FastAPI
from fastapi.responses import JSONResponse
from redis import asyncio as aioredis
import json

app = FastAPI()
redis = aioredis.from_url("redis://localhost")

@app.get("/produto/{id}")
async def get_produto(id: int):
    cache_key = f"produto:{id}"
    cached = await redis.get(cache_key)
    if cached:
        return JSONResponse(content=json.loads(cached))

    # Simula consulta ao banco (substitua aqui pela sua query real)
    produto = {"id": id, "nome": "Produto X", "preço": 99.90}

    # Cache com TTL de 60 segundos
    await redis.setex(cache_key, 60, json.dumps(produto))
    return produto

Ambiente rápido com Docker

Se ainda não tem o Redis rodando, um docker-compose resolve em segundos:

services:
  redis:
    image: redis:alpine
    ports:
      - "6379:6379"

Quando usar (e quando não usar)

Cache é perfeito para leituras frequentes e tolerância a staleness controlada. Já para dados que mudam a todo instante (ex.: saldo financeiro em tempo real), o custo de invalidação pode superar o benefício. E não esqueça: defina TTLs realistas e instrumente a taxa de cache hit.

O erro que consome recursos sem você notar

SELECT * é o vilão silencioso. Trazer todas as colunas — inclusive aquelas com textos longos ou BLOBs — quando a rota só precisa de nome e preço desperta duas dores: tráfego de rede maior e mais memória ocupada no lado da aplicação.

A abordagem cirúrgica com load_only

No SQLAlchemy (modo async), você pode limitar as colunas carregadas diretamente na query:

from sqlalchemy.orm import load_only
from sqlalchemy import select

stmt = select(Produto).options(load_only(Produto.nome, Produto.preço))
result = await db.execute(stmt)
produtos = result.scalars().all()

Não pare por aí

Combine isso com índices nas colunas usadas nos filtros (WHERE) e nos JOIN. Para tabelas grandes, uma indexação bem pensada reduz o tempo de query de segundos para milissegundos. Ferramentas como pg_stat_statements (PostgreSQL) ou o EXPLAIN do MySQL são suas aliadas para caçar full table scans.

Por que isso importa?

APIs que retornam payloads JSON extensos ou listas grandes desperdiçam banda e aumentam o tempo de transferência, especialmente em redes móveis. A compressão GZip ataca exatamente isso.

Ativação em uma linha (bom, duas)

O FastAPI já tem middleware nativo:

from fastapi.middleware.gzip import GZipMiddleware

app.add_middleware(GZipMiddleware, minimum_size=500)

O gargalo invisível do front-end

SPA com muitos componentes, bibliotecas de gráficos e modais pode resultar em um bundle inicial gigante. O usuário espera segundos olhando para uma tela em branco — e isso anula todo o esforço feito no back-end.

A solução: carregue sob demanda

Com Vue 3, componentes assíncronos são declarados assim:

import { defineAsyncComponent } from 'vue';

const ModalLogin = defineAsyncComponent(() => import('@/components/ModalLogin.vue'));

Para rotas, ainda mais elegante

Se você usa Vue Router, o lazy loading das páginas já é o padrão recomendado:

const routes = [
  { path: '/dashboard', component: () => import('@/views/Dashboard.vue') }
];

Automatizando com Vite

O plugin vite-plugin-pages cria rotas automáticas baseadas na estrutura de arquivos e já aplica code splitting. Combine isso com vite-plugin-vue-layouts e você terá uma base de projeto enxuta e rápida por padrão.

O que você ganha?

Menor tempo até a primeira renderização (FCP) e melhor pontuação no Lighthouse. O código do modal de login, por exemplo, só é baixado quando alguém clica em “Entrar”.

O desafio

Uma loja online usando FastAPI + Vue.js começou a travar nos picos de acesso. A página de listagem de produtos levava 2 segundos para carregar, e o banco de dados chegava a 80% de CPU.

Resultado

Latência média da página de produtos caiu de 2000ms para 400ms. O uso de CPU do servidor foi reduzido em 40%, e o banco de dados passou a operar com folga. Detalhe: o Redis introduziu uma latência extra de apenas 2ms no cache hit, totalmente aceitável.

❌ Misturar código síncrono em rotas assíncronas: usar requests.get dentro de async def é pedir para degradar performance.

❌ Esquecer o pool de conexões do banco: criar uma nova conexão a cada requisição derruba qualquer aplicação sob carga. Configure o pool adequadamente.

❌ Não monitorar: sem Prometheus + Grafana (ou pelo menos logs estruturados) você está voando às cegas. Erros de performance aparecem quando o cliente já foi embora.