Definitivamente hay ventajas y desventajas sobre el uso de JSON sobre REST frente a TCP / IP directo con protocolo binario y creo que ya sospecha que el protocolo binario será más rápido. No puedo decir exactamente cuánto más rápido (y esto dependería de muchos factores), pero supongo que tal vez una diferencia de 1-2 órdenes de magnitud.
A primera vista, si algo es 10-100 veces más lento que otra cosa, es posible que tenga una reacción instintiva e intente "algo rápido". Sin embargo, esta diferencia de velocidad es solo en el protocolo en sí. Si hay acceso a la base de datos / archivos en el lado del servidor, eso no se verá afectado por la elección de la capa de transferencia. En algunos casos, puede hacer que la velocidad de la capa de transferencia sea mucho menos significativa.
HTTP REST y JSON son buenos por varias razones:
- son fácilmente consumibles por casi cualquier persona. Puede escribir su aplicación web, luego dar la vuelta y publicar su API para que la use el resto del mundo. Ahora cualquiera puede alcanzar los mismos puntos finales y acceder a sus servicios
- son fácilmente depurables, puede abrir un sniffer de paquetes o simplemente volcar las solicitudes entrantes en archivos de texto y ver qué sucede. No puedes hacer eso con protocolos binarios
- Son fácilmente extensibles. Puede agregar más atributos y datos más adelante y no romper la compatibilidad con clientes antiguos.
- consumible por clientes javascript (no estoy seguro de que tengan protobuf JS parser todavía, no creo que haya uno)
Protobufs sobre TCP / IP:
Si fuera mi elección, sin duda iría con HTTP REST y JSON. Hay una razón por la que muchas otras compañías y sitios web tomaron esa ruta. También tenga en cuenta que en el futuro siempre podría admitir 2 puntos finales. Si su diseño es correcto, su elección de punto final debe estar completamente desacoplada de la lógica de negocios del lado del servidor o de la base de datos. Entonces, si luego se da cuenta de que necesita más velocidad para todas / algunas solicitudes, debería poder agregar protobufs con un mínimo de alboroto. Sin embargo, REST / JSON lo levantará del suelo más rápido y lo llevará más lejos.
En cuanto a Netty vs Spring. No he usado Netty directamente, pero creo que es solo un servidor web liviano donde Spring es un marco que proporciona mucho más para ti que eso. Tiene capas de acceso a datos, programación de trabajos en segundo plano y (creo) un modelo MVC, por lo que es mucho más pesado. ¿Cuál elegir? Si decidió seguir el camino HTTP, entonces la siguiente pregunta es, ¿qué tan estándar es su aplicación? Si está a punto de escribir una lógica personalizada loca que no se ajusta al molde estándar y todo lo que necesita es solo una capa de servidor HTTP, vaya con Netty.
Sin embargo, sospecho que su aplicación no es tan especial y probablemente podría beneficiarse de muchas cosas que Spring tiene para ofrecer. Pero eso significa que debe estructurar su aplicación en torno al marco de Spring y hacer las cosas como ellos esperan que haga, lo que significaría aprender más sobre Spring antes de sumergirse en su producto. Los marcos en general son geniales porque nuevamente te hacen despegar más rápido, pero la desventaja es que tienes que encajar en su molde en lugar de hacer tu propio diseño y luego esperar que el marco funcione.
(*) - en el pasado se señaló que mis publicaciones no reflejan las opiniones del mundo entero, así que iré al registro y solo agregaré que tengo una experiencia limitada con Netty (he usado el marco de Play antes que se basa en Netty) o Spring (solo he leído sobre eso). Así que toma lo que digo con un grano de sal.