Definitivamente, existem prós / contras sobre o uso de JSON sobre REST vs. TCP / IP direto com protocolo binário e acho que você já suspeita que o protocolo binário será mais rápido. Não sei exatamente o quanto mais rápido (e isso dependeria de muitos fatores), mas acho que talvez haja uma ou duas ordens de diferença de magnitude.
À primeira vista, se algo é 10 a 100 vezes mais lento do que qualquer outra coisa, você pode ter uma reação brusca e optar por "coisa rápida". No entanto, essa diferença de velocidade está apenas no próprio protocolo. Se houver acesso ao banco de dados / arquivo no lado do servidor, isso não será afetado por sua escolha da camada de transferência. Em alguns casos, isso pode tornar a velocidade da camada de transferência muito menos significativa.
HTTP REST e JSON são válidos por vários motivos:
- eles são facilmente consumíveis por praticamente qualquer pessoa. Você pode escrever seu Web App, virar e publicar sua API para o resto do mundo. Agora qualquer pessoa pode atingir os mesmos pontos finais e acessar seus serviços
- eles são facilmente depuráveis, você pode abrir um farejador de pacotes ou simplesmente despejar solicitações recebidas em arquivos de texto e ver o que está acontecendo. Você não pode fazer isso com protocolos binários
- eles são facilmente extensíveis. Você pode adicionar mais atributos e dados posteriormente e não quebrar a compatibilidade com clientes antigos.
- consumível por clientes javascript (ainda não tenho certeza de que eles têm um analisador de protobuf JS, não acredito que exista)
Protobufs sobre TCP / IP:
Se fosse minha escolha, eu usaria o HTTP REST e o JSON. Há uma razão para tantas outras empresas e sites seguirem esse caminho. Lembre-se também de que no futuro você sempre poderá oferecer suporte a 2 pontos finais. Se seu design estiver correto, sua escolha do ponto final deve ser completamente dissociada da lógica de negócios do servidor ou do banco de dados. Portanto, se você perceber mais tarde que precisa de mais velocidade para todas / algumas solicitações, poderá adicionar protobufs com o mínimo de barulho. Logo de cara, no entanto, o REST / JSON o levará mais rápido do chão e o levará adiante.
Tanto quanto Netty vs Spring vai. Não usei o Netty diretamente, mas acredito que seja apenas um servidor da Web leve, pois o Spring é uma estrutura que fornece muito mais para você do que apenas isso. Ele possui camadas de acesso a dados, agendamento de tarefas em segundo plano e (eu acho) um modelo MVC, por isso é muito mais pesado. Qual escolher? Se você decidiu seguir o caminho HTTP, a próxima pergunta provavelmente é qual é o padrão do seu aplicativo. Se você está prestes a escrever uma lógica personalizada maluca que não se encaixa no molde padrão e tudo que você precisa é apenas uma camada de servidor HTTP, vá com o Netty.
No entanto, desconfio que seu aplicativo não seja tão especial e provavelmente poderia se beneficiar de muitas coisas que o Spring tem a oferecer. Mas isso significa que você deve estruturar seu aplicativo em torno da estrutura do Spring e fazer as coisas da maneira que eles esperam, o que significaria aprender mais sobre o Spring antes de mergulhar em seu produto. As estruturas em geral são ótimas porque, mais uma vez, tiram você do papel mais rapidamente, mas a desvantagem é que você precisa se encaixar no molde delas, em vez de fazer seu próprio design, e esperar que a estrutura funcione.
(*) - no passado, foi apontado que minhas postagens não refletem opiniões de todo o mundo, por isso vou gravar e acrescentar que tenho uma experiência limitada com o Netty (já usei o framework Play antes que é baseado no Netty) ou no Spring (eu só li sobre isso). Então pegue o que eu digo com um grão de sal.