Processamento síncrono significa que as tarefas ocorrem em sequência. Cada requisição é tratada completamente antes da próxima começar. Primeiramente, Django e Flask são frameworks majoritariamente síncronos. FastAPI também suporta o modo síncrono, embora seja famoso pelo assíncrono. Por exemplo, um endpoint que consulta um banco de dados bloqueia a execução. O servidor não aceita novas conexões enquanto processa essa operação. A voz passiva é usada aqui: “cada linha de código é executada em ordem”. Quando utilizar código síncrono? Na maioria das aplicações web tradicionais. Blogs, sistemas administrativos e e-commerces funcionam bem assim. A simplicidade do síncrono reduz bugs e facilita a depuração. Além disso, o custo mental para desenvolvedores é menor. Portanto, não se sinta pressionado a usar async sem necessidade real. Vamos explorar como cada framework lida com o paradigma síncrono. Três subtítulos guiarão nossa análise comparativa.
Django: o gigante síncrono e full-stack
Django é totalmente síncrono por design e tradição. Cada requisição roda em um processo ou thread separada. O servidor WSGI (como Gunicorn) gerencia o paralelismo real. Dentro de uma view, o código executa linha após linha. Isso é previsível e fácil de testar. Django oferece ORM síncrono, cache e autenticação prontos. Quando usar Django síncrono? Em projetos grandes e monolíticos. Por exemplo, portais de notícias ou sistemas de gestão. A desvantagem é o bloqueio durante I/O (acesso a banco ou API externa). Contudo, para 95% dos casos, isso não é um problema. A fórmula do tempo total de resposta: \(T = \sum_{i=1}^{n} t_i\). Onde \(t_i\) é o tempo de cada operação sequencial. Um exemplo simples de view síncrona no Django:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
# views.py no Django from django.http import JsonResponse from django.db import connection import time def consulta_demorada(request): # Operação síncrona que bloqueia with connection.cursor() as cursor: cursor.execute("SELECT COUNT(*) FROM usuarios") resultado = cursor.fetchone() time.sleep(1) # Simula processamento pesado return JsonResponse({'total': resultado[0]}) |
Essa view trava o processo por pelo menos um segundo. Outras requisições aguardam em fila se houver poucas threads. A solução é aumentar o número de processos ou threads no Gunicorn. Django síncrono é robusto e testado há mais de 15 anos.
Flask: flexibilidade síncrona com micro núcleo
Flask também opera no modo síncrono por padrão. Cada rota é uma função que bloqueia até retornar. Ele é mais leve e minimalista que o Django. Quando usar Flask síncrono? Em APIs pequenas e protótipos. Também é excelente para microsserviços simples. A falta de estrutura impõe decisões sobre ORM e autenticação. Por outro lado, você escolhe exatamente o que precisa. O servidor padrão do Flask não é para produção. Use Gunicorn ou Waitress com múltiplos workers. A voz passiva é aplicada: “as extensões são integradas conforme necessário”. Flask síncrono é perfeito para aprender conceitos de backend. Seu código é explícito e sem mágicas. Veja um exemplo de API síncrona com Flask:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
from flask import Flask, request, jsonify import requests app = Flask(__name__) @app.route('/clima', methods=['GET']) def clima_sincrono(): cidade = request.args.get('cidade', 'São Paulo') # Chamada síncrona para API externa (bloqueia) resposta = requests.get(f'https://api.exemplo.com/clima?q={cidade}') dados = resposta.json() return jsonify(dados) if __name__ == '__main__': app.run() |
Note que requests.get() bloqueia até a resposta voltar.
Durante esse tempo, o servidor não atende outras requisições no mesmo worker.
Para alta concorrência, aumente o número de workers.
Flask síncrono é claro, direto e suficiente para muitas aplicações.
FastAPI no modo síncrono: o melhor de dois mundos
FastAPI suporta funções síncronas e assíncronas livremente.
Você pode escrever def minha_rota(): (síncrono) ou async def.
O framework gerencia automaticamente a execução correta.
Quando usar FastAPI síncrono? Em operações com CPU intensiva.
Cálculos pesados, processamento de imagens ou criptografia.
Nesses casos, o modo assíncrono não traria ganhos reais.
Porém, FastAPI foi construído para alta performance mesmo no síncrono.
Ele utiliza o servidor Uvicorn (ASGI) com threads para funções síncronas.
Isso evita bloqueio total do event loop.
A documentação automática (Swagger) funciona perfeitamente.
Uma vantagem adicional: migrar de síncrono para assíncrono é fácil.
Basta adicionar async e trocar bibliotecas como httpx no lugar de requests.
Exemplo de endpoint síncrono no FastAPI:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
from fastapi import FastAPI import hashlib import time app = FastAPI() @app.get('/hash-sincrono') def calcular_hash(texto: str): """Função síncrona com CPU-bound (hash).""" inicio = time.time() for _ in range(100000): resultado = hashlib.sha256(texto.encode()).hexdigest() fim = time.time() return { 'hash': resultado, 'tempo_segundos': round(fim - inicio, 2) } # Rode com: uvicorn arquivo:app --reload |
Esse código consome CPU pura, não I/O. O modo síncrono é ideal aqui, pois async não aceleraria. Portanto, escolha FastAPI quando quiser flexibilidade para o futuro. Resumo final: Django é completo e síncrono. Flask é simples e leve. FastAPI é rápido e híbrido. Todos os três servem bem para a maioria dos projetos. Comece com o que parece mais natural para seu time.