Web Charting, lado del servidor o del lado del cliente?

Question

Estoy tratando de establecer si estamos mejor haciendo gráficos en el servidor y empujándolos hacia el navegador como imágenes o usando una biblioteca de gráficos javascript para dibujar los cuadros al lado del cliente.

Estoy mirando las bibliotecas JFreeChart y Dojo Charting, mi objetivo es un sitio JSP existente que se ejecuta en JBoss.

¿Alguien tiene alguna experiencia con esto que pueda señalar los méritos/defectos de cada uno?

Por el momento estoy viendo la representación del lado del cliente como mucho más eficiente a menos que el conjunto de datos sea enorme.

Answer 1

Me gustaría recomendar una biblioteca que escribí: charts4j que es una solución de gráficos del lado del servidor. Aquí están algunas características:

• soportan casi todas las características de la Google Chart API
• oculta los detalles feos de la creación de los parámetros de URL que son necesarios para comunicarse con el Google Chart API
• pueden ser incorporados en activar ningún sitio de Internet Entorno de aplicación Swing o web (JSP/Servlet, GWT, Spring MVC, etc.)
• Solución Java 100% pura. No es necesario tener bibliotecas de gráficos especiales, etc.
• Súper escalable & Ligero. Solo se requiere un frasco de 160 KB y una conexión a Internet.
• Bien documentado
• Lo mejor de todo es que es GRATUITO.

Éstos son algunos testimonials. También echa un vistazo a FAQ.

Tengo un ejemplo de incorporación de esta tecnología en una aplicación Spring MVC (usando JSP) en my blog.

Answer 2

JFreeChart está muy bien establecido y ha estado en funcionamiento durante muchos años. Lo he usado en proyectos anteriores y ha funcionado muy bien. Se puede usar desde una aplicación cliente enriquecida o desde una aplicación web. Tiene aplicaciones de ejemplo para ambos escenarios. Si está distribuyendo su aplicación, también tiene licencia GPL.

Las ventajas de hacerlo en el lado del servidor son que puede representar el gráfico resultante como una imagen y no preocuparse por la compatibilidad de varios navegadores. He incorporado JFreeChart al renderizar desde un Servlet y desde Struts, funciona muy bien.

No puedo hablar de los gráficos Dojo, ya que es razonablemente nuevo.

Answer 3

El primer factor decisivo debe ser si necesita o no que los gráficos sean accesibles con JavaScript desactivado. Si lo hace o cree que podría hacerlo, descarta completamente el JavaScript.

Answer 4

Veo una gran cantidad de puntos válidos en ambos lados, pero una cosa que me gusta de hacer el lado del cliente de gráficos, es la capacidad de hacer algo de interacción con el gráfico. Usando la biblioteca de gráficos de Dojo, tiene una variedad de métodos para la interacción de gráficos como dojox.charting.action2d.Highlight y dojox.charting.action2d.Tooltip. También puede hacer que sus gráficos se actualicen dinámicamente sin necesidad de actualizar, y puedo ver algunas situaciones en las que eso puede ser útil.

Por supuesto, esto depende de usted, pero me gustan los gráficos con los que puedo interactuar mucho mejor que las imágenes renderizadas desde el servidor, y creo que mucha gente está de acuerdo conmigo en eso.

Answer 5

Recomendaría determinar sus necesidades de rendimiento/aprovisionamiento y tomar una decisión desde allí. Si está esperando una gran cantidad de clientes, cada uno de los cuales requiere una gran cantidad de gráficos que pueden necesitar actualizar periódicamente, es probable que la mejor solución sea descargar el procesamiento a los clientes. Como mencionó Jesper, también podría hacer más interacción directamente con los gráficos en el cliente, en lugar de requerir devoluciones de llamada al servidor para una funcionalidad más compleja.

Si el modelo de uso general para sus gráficos es simple (por ejemplo, gráficos estáticos generados sobre la marcha por el servidor, sin necesidad de actualizar), y el número de clientes es bajo, puede estar bien usando hardware para mejorar mejor el rendimiento. Servidor-lado probablemente sería suficiente en este caso.

La escalabilidad y el rendimiento pueden ser difíciles de implementar más adelante en el futuro. Si tiene el potencial para mitigar esto desde el principio, debe hacerlo, ya que los modelos de uso actuales cambian a menudo a medida que los futuros usuarios deciden que necesitan una funcionalidad más rápida/mejor.

Answer 6

Si va con Javascript, es posible que también desee una solución del lado del servidor, en caso de que javascript esté desactivado.

Si utiliza javascript discreto, si Javascript está activado, puede cambiar los enlaces de la solución del lado del servidor para usar una herramienta de creación de gráficos de javascript.

Encontré lo mejor para usar php en el lado del servidor como gdlib es bueno, y mi servidor tomcat arrojaba errores a veces debido a no poder conectarse a un servidor x11, incluso si se ejecutaba en modo sin cabeza.

Hay muchas soluciones posibles, o puede hacerlo usted mismo. Graficar no es difícil, depende de lo que necesita. Por ejemplo, si puede usar svg, eso permitiría gráficos animados, pero necesita un complemento para muchos navegadores.