1) REST sobre HTTP/JSON: simplicidade, interoperabilidade e cache

Eu gosto de começar por REST quando a prioridade é simplicidade de consumo, maturidade do ecossistema e facilidade de integração com clientes web. REST sobre HTTP é naturalmente compatível com proxies, caches, CDNs e ferramentas de observabilidade. A principal troca de vantagem/desvantagem está na previsibilidade de contratos versus over-fetching.

• Vantagens: tooling amplo, facilidade de evolução de interfaces via versionamento cuidadoso, cache HTTP em nível de recurso, excelente compatibilidade com navegadores e clientes móveis, boa experiência para equipes que precisam de entregas rápidas com mudanças incrementais.
• Desvantagens: podem ocorrer fetches redundantes (over-fetching), múltiplos endpoints para operações correlacionadas, e a modelagem de dados pode exigir mapeamentos entre esquemas ricos e recursos REST simples.
• Caso de uso típico: APIs públicas, integrações com clientes web/Mobile, cenários onde a latência é aceitável e a comunicação é predominantemente request/response.

2) GraphQL: queries flexíveis, esquemas unificados e evolução orientada a cliente

GraphQL brilha quando os clientes precisam escolher exatamente quais dados retornar, reduzindo o over-fetching sem depender de várias chamadas. Em equipes onde clientes móveis e web evoluem rapidamente, um único endpoint com um esquema refletindo o domínio ajuda a manter a consistência entre serviços.

• Vantagens: consultas diretas ao formato de dados desejado, redução de round-trips em cenários complexos, introspecção de esquema para auto-documentação, bom para dados conectados com relacionamentos ricos.
• Desvantagens: caching mais complexo, maior responsabilidade no servidor (resolvers), possibilidade de complexidade de consultas e risco de queries caras sem rate limiting, evolução de esquema requer governança cuidadosa.
• Caso de uso típico: APIs de dashboards, UIs com necessidade de dados variados de várias entidades, cenários onde clientes demandam personalização de payloads.

// Exemplo simples de schema GraphQL (SDL)
type User {
  id: ID!
  name: String!
  email: String
}
type Query {
  user(id: ID!): User
  users: [User!]!
}

3) RPCs de alto desempenho: Thrift, Cap’n Proto e FlatBuffers

Quando a prioridade é latência ultrabaixa, throughput alto e/ou suporte a múltiplos transportes (além de HTTP), estas opções podem superar as restrições de HTTP/JSON ou exigir menos serialização/ desserialização em pontos críticos do pipeline. A escolha depende do ecossistema existente, da maturidade da linguagem e do domínio do seu negócio.

• Thrift: IDL bem estabelecido, suporte a múltiplas linguagens e transports. É uma boa opção se você precisa de interoperabilidade entre muitos serviços legados ou se já tem uma stack Thrift. Pode ser usado com transportes não-HTTP quando se busca performance ou requisitos de rede específicos.
• Cap’n Proto: foco extremo em performance com zero-copy; excelente para cenários de alto throughput dentro de infraestruturas controladas. O ecossistema é menor que Thrift/gRPC, portanto avalie o trade-off entre maturidade e ganhos de performance.
• FlatBuffers: excelente para dados principalmente de leitura com exigência de baixa latência. Útil em jogos, streaming de dados e ambientes com desempenho sensível, ainda que não seja um framework RPC completo por si só.

// Exemplo simples de IDL Thrift (IDL genérico)
namespace js example

struct User {
  1: i32 id,
  2: string name,
  3: string email
}
service UserService {
  User getUser(1:i32 id),
  list listUsers()
}

Observação: a adoção de Thrift/Cap’n Proto/FlatBuffers costuma exigir uma estratégia de transporte dedicada, além de considerações sobre multi-linguagem e tooling. Em muitos cenários, gRPC continua sendo o caminho mais pragmático para APIs modernas, especialmente quando já há suporte sólido para streaming e open-API/IDL padronizados.

4) Messaging e arquitetura orientada a eventos

Para cenários onde a desacoplabilidade, resiliência e escalabilidade são cruciais, descolar a comunicação via mensagens assíncronas pode ser a melhor escolha. Sistemas como Kafka, NATS e AMQP permitem pipelines de dados, backpressure e entrega garantida, mantendo os serviços independentes e mais fáceis de evoluir.

• Vantagens: alto isolamento entre serviços, buffers de backpressure, replayability de eventos, integração com padrões de Event Sourcing e CQRS.
• Desvantagens: eventual consistency, complicação de depuração, necessidade de padrões de idempotência e observabilidade mais sofisticados.
• Caso de uso típico: pipelines de dados, eventos de domínio, notificações assíncronas, integrações entre microserviços que não requerem resposta imediata.

Conclusão e próximos passos

Escolher a alternativa certa não é apenas sobre desempenho: envolve governança, maturidade da equipe e requisitos de arquitetura. Minha prática combina REST ou gRPC para fluxo principal de chamadas síncronas, GraphQL quando a clientelos exige flexibilidade, e arquitetura orientada a eventos para cenários com desacoplamento e escalabilidade. Use a ferramenta certa no contexto certo.