search

hurbcom / challenge-bravo

Backend code challenge
167 stars 299 forks source link

API Interna ou Externa? #10

Closed fabriciopf closed 6 years ago

fabriciopf commented 6 years ago

Caso essa API em questão seja uma API interna, não seria o caso de desenvolver um RPC e mudar o protocolo para Protobuf invés de JSON?

Por sinal, a gRPC é compatível com todas as linguagens que o HU tem afinidade.

zanaca commented 6 years ago

Essa é uma boa pergunta! Mas por que seria um limitador o uso interno da API para ir para o protobuf?

O @bernardolm está montando um POC de uso do RPC.

zanaca commented 6 years ago

O gRPC realmente seria mais transparente para fazer a mudança, mas tem uma turma que não têm bons olhos para o gRPC...

bernardolm commented 6 years ago

Fala @fabriciopf, tudo bem? Esses pontos que Spencer Nelson, você consegue comentar?

fabriciopf commented 6 years ago

Oi, pessoal! Blz? @zanaca, você tem toda razão, o uso interno/externo da API não seria um limitador. Quando fiz essa pergunta, na verdade, foi pra eliminar a possibilidade de ser uma API pública, utilizada por terceiros. Quando a solução exige certa legibilidade do payload (em JSON, principalmente) e facilidade para integrar com outros sistemas a solução REST tende a vencer facilmente essa disputa RPC vs REST.

Sobre o gRPC, tem pouquíssimo tempo que comecei a sujar minhas mãos com isso. Estou trabalhando numa POC também e um dos desafios que ainda não pensei como resolver é a questão da escalabilidade (ELB), como foi citada no artigo do SN. A propósito, meu caso é específico para clientes que estabelecem conexões permanentes com o servidor.

@bernardolm , tudo certo? Segue abaixo meus comentários sobre o artigo:

  1. Lack of HTTP 1.1 support: Entendi que eles decidiram adicionar o suporte a HTTP 1.1 para resolver, principalmente, questões de compatibilidade com LBs. Porém, essa não é a única solução para esse problema e o custo dela foi bem caro, na minha opinião. Perdeu-se o suporte a streaming e fiquei na dúvida se a full-duplex (envio e recebimento simultâneo) e a "Server Push" também!

  2. Large runtime with breaking changes: Não venho acompanhando a evolução do gRPC e também ainda não analizei o footprint da minha POC. Realmente, ter que utilizar a mesma versão do gRPC runtime nos clientes e servidores pode ser um soco no estômago. Preciso verificar melhor e ver como é na prática.

  3. Bugs due to the complex runtime: Ok, ponto para o Twirp pela sua simplicidade. O que se perdeu com isso? A performance é a mesma?

  4. Difficulty working with binary protobuf: Legal! Protobuf codificado em JSON ajuda a resolver o que citei inicialmente sobre o uso da API por terceiros. Mas vale lembrar que o "binary protobuf" é bem compactado e pode reduzir drasticamente o uso da banda.

Resumindo, ainda não tinha ouvido falar sobre o Twirp e minha opinião precoce é que ele, de fato, é uma solução melhor que o gRPC para o Twitch mas não parece ser uma solução com suporte mais abrangente a outros casos de uso - principalmente os que fazem uso dos benefícios do HTTP/2. Entendo também que o Twirp deve ter levado um bom tempo pra ser desenvolvido e desde então pode ser que o gRPC já tenha resolvido algumas dessas questões. Obviamente, eles vão puxar sardinha pro lado deles. Afinal, estão anunciando sua ferramenta! :)

Enfim, gostaria de poder ter contribuído mais. Teria que entender qual é a realidade do HU e quais são as necessidades para, aí sim, poder opinar melhor sobre alguma decisão de escolha entre uma solução ou outra. E espero que essa oportunidade chegue logo!! Até lá, continuarei estudando mais.

Estou curioso pra saber a opinião de vocês sobre essas questões! :)

renatovico commented 6 years ago

:+1: