Na Riiid, que opera o Santa TOEIC, usamos gRPC/Protobuf de forma muito ativa.
Pouco tempo depois de eu entrar na Riiid, fui informado de que, dali em diante, todas as APIs fornecidas pela equipe de backend para o frontend (mobile/web) seriam padronizadas em gRPC.
Para usar a stack de gRPC/Protobuf no frontend web, antes havia opções como usar o protoc com plugins de JS/TS ou utilizar o Protobuf.js.
O plugin oficial de JS do protoc tinha o problema de gerar código em um estilo muito antigo, e os plugins do ecossistema também não atendiam a todos os nossos requisitos. Também havia o incômodo de depender de um binário nativo (protoc). (Hoje em dia, também existe o problema de ser difícil instalar o protoc em máquinas M1.)
Nós usamos o Protobuf.js para criar vários produtos até então, mas, como todas as interfaces de comunicação entre plataformas nos produtos criados pela empresa passaram a usar Protobuf, percebemos que o Protobuf.js não estava maduro no nível de que precisávamos.
Enfrentamos vários problemas, como casos em que mensagens com o mesmo nome eram confundidas com mensagens de outro namespace, situações em que a geração de código de tipo de mensagem falhava quando uma declaração de mensagem vinha após um enum no namespace global, ou ainda quando as definições de tipo em TypeScript diferiam do comportamento do JS gerado.
Nesse processo, criamos o pollapo, um gerenciador de pacotes para protobuf, para montar um sistema que compilasse apenas os schemas protobuf necessários para cada produto.
(Na época, existiam outros gerenciadores de dependência para protobuf, mas eles tinham bugs ou problemas como não suportar dependências aninhadas. Além disso, o recurso de gerenciamento de pacotes oferecido pelo buf existia apenas em um post de blog dizendo que estava em desenvolvimento, e não ficou pronto até concluirmos a criação do pollapo e a migração interna.)
Com o pollapo, reduzimos bastante a quantidade de schemas compilados por produto, e diminuímos os bugs causados por nomes de mensagem iguais e afins, mas ainda assim continuavam existindo bugs e problemas de build. Para resolver isso, criamos diretamente um compilador de protobuf para TypeScript.
O Santa TOEIC já concluiu a substituição completa do Protobuf.js pelo pbkit.
Os apps desenvolvidos na Riiid, incluindo o Santa TOEIC, usam WebView de forma intensa.
O WebView se comunica com o nativo para obter informações do dispositivo/usuário ou do conteúdo exibido no momento, e a interface dessa comunicação também é definida usando schemas de serviço Protobuf.
No pbkit, ao gerar código de serviço, é fornecida uma interface que permite trocar a camada de rede por outro protocolo em vez de gRPC.
Os engenheiros de frontend web que usam o compilador do pbkit não precisam saber se, ao se comunicar com o nativo mobile, estão fazendo requisições via gRPC ou via o protocolo App Bridge acordado com os engenheiros mobile.
Além disso, como também desenvolvemos diretamente uma extensão para Chrome, é possível verificar com facilidade, na aba do pbkit nas ferramentas de desenvolvedor do Chrome, o conteúdo da comunicação com o mobile, como se fosse a aba de rede.
Como criamos diretamente o compilador de schema protobuf, pensamos que seria possível implementar rapidamente recursos como Go to Definition no editor de código, e por isso também criamos uma extensão para VSCode.
Até então, as extensões de protobuf voltadas ao VSCode ofereciam apenas recursos como destaque de sintaxe, mas a extensão pbkit para VSCode inclui um recurso de Go to Definition que realmente funciona.
Daqui para frente, planejamos desenvolver suporte a outras linguagens como swift/kotlin/python, suporte a casos de uso de servidor, ferramentas de geração de documentação e ferramentas de linting/formatação.
Também estamos procurando engenheiros para desenvolver essas ferramentas conosco: https://riiid.com/ko/career/dx-software-engineer
Agradecemos o interesse de todos.
Repositório do pbkit: https://github.com/pbkit/pbkit
Extensão para VSCode: https://marketplace.visualstudio.com/items?itemName=pbkit.vscode-pbkit
Extensão para Chrome: https://chrome.google.com/webstore/detail/pbkit-devtools/fjacmiijeihblfhobghceofniolonhca
9 comentários
Na nossa empresa, alguns anos atrás, acabamos escolhendo Thrift depois de comparar com gRPC. O gerador de JS do Thrift também era incompleto, então tivemos que modificá-lo por conta própria, e percebemos que isso não é algo que vale a pena fazer. Aí fiquei pensando se deveríamos ter escolhido gRPC, mas pelo visto a situação por lá também não é das melhores.
Depois disso, escolhemos GraphQL, e eu estou satisfeito. Às vezes me preocupo com o overhead de comunicação, mas realmente não consigo usar protocolos baseados em binário.
Estamos usando muito bem no Danggeun Market!! ( _ _ )
Estamos nos esforçando para aproveitar bem isso para malha de APIs internas, haha
Uau, isso é incrível!
Uau, então você criou o compilador por conta própria. Muito legal! (Eu estava curioso sobre como o código em golang é gerado, mas pelo visto atualmente ele só oferece suporte a deno e node.js.) Eu costumo usar protoc ou buf junto com ts-proto, então fiquei curioso para saber qual é a diferença no código ts gerado em comparação com o ts-proto.
Parece meio dar uma volta desnecessária, né https://github.com/trpc/trpc
bichi / No caso de a API do servidor ser fornecida pelo protocolo gRPC, o trcp não seria algo para dar suporte a isso, certo~?
Concordo que usar a stack de gRPC/Protobuf não é o ideal. (Não fui eu que escolhi usar, foi por questões da empresa.)
Ainda assim, como o tRPC define interfaces usando
zod, parece ser ideal quando se usa TypeScript em todas as plataformas.No nosso ambiente, em que o servidor é escrito em Kotlin, acho que seria difícil de usar, e também não parece adequado para casos de comunicação com mobile nativo (Swift, Kotlin).
Posts sobre gRPC são sempre bem-vindos :)
Uau, até extensão para VS/Chrome no código... muito legal!! Torcendo por vocês.
O texto de apresentação ficou muito bem escrito, então acho que quem visitar pelo GeekNews vai acabar levando mais informações do que quem só entrar no repo ^^;
Se quem estiver usando Protobuf atualmente deixar um comentário, acho que vai ajudar bastante.