html5 - software - Arquitectura del lado del servidor para aplicaciones web móviles

programar apps multiplataforma

Question

En la mayoría de las aplicaciones web de escritorio en las que he trabajado, necesita un marco web del lado del servidor. El marco web del lado del servidor (Struts, Spring MVC, etc.) tiene algún tipo de controlador para procesar solicitudes y luego un motor de plantillas (Velocity, JSP, etc.) para generar contenido dinámico.

Ahora estoy empezando a trabajar en aplicaciones web móviles y todas las discusiones que veo giran en torno a la selección de un marco de interfaz de usuario (jQuery Mobile, jQTouch, Sencha Touch, etc.) pero no veo ninguna discusión sobre lo que está sucediendo en el servidor para procesar realmente las solicitudes HTTP o para generar el HTML, CSS y JavaScript.

¿Esto significa que la mayoría de las aplicaciones web móviles no usan un marco web del lado del servidor ... lo que significa que el servidor sirve contenido estático, la mayoría del comportamiento interactivo está codificado en JavaScript, y el único código del lado del servidor son los servicios REST que el El cliente de JavaScript carga?

Si quisiera usar un marco web del lado del servidor, ¿sería una mala idea? ¿Qué problemas tendría? ¿Alguien tiene una recomendación sobre el marco web que sea una plataforma productiva y no "interponerse" en los marcos de la interfaz de usuario móvil como jQuery mobile?

NOTA: Los desarrolladores con los que trabajo provienen principalmente de fondos Java empresariales, sin embargo, no lo limitaría solo a framoworks web basados ​​en Java. Existen otros marcos que tienen raíces en Java que podrían considerarse (Grails, Lift, etc.).

Answer 1

Eche un vistazo a ItsNat , ItsNat lo invita a pensar en el JavaScript del cliente pero codificando en Java y ejecutándolo en el servidor generando el mismo código JS para el cliente.

La diferencia con GWT es que el código Java W3C DOM se ejecuta en el servidor y JS se genera automáticamente, mientras tanto GWT se ejecuta en el cliente, los datos del servidor deben ser transportados al cliente.

Answer 2

Una buena pregunta segura y la responderé de esta manera. La tendencia actual es construir una gran cantidad de interactividad en la parte delantera. Hay varias razones para esto. Algunos lo hacen porque es lo nuevo, otros lo hacen porque intentan replicar la experiencia de escritorio. Al final, solo hay un objetivo para cualquier proyecto web dado y es crear la Experiencia de usuario mejor y más sostenible.

Habiendo dicho eso , habría que evitar las tecnologías del lado del servidor y eso sería algo que generaría la interfaz pero no usaría jQuery. Más del 45% de todos los sitios web de hoy usan jQuery y si seleccionas algo más, estarás instantáneamente en desacuerdo con los marcos móviles vigentes. (GWT, IceFaces, te estoy mirando).

Probablemente la forma más segura y más flexible de hacerlo sea utilizar una implementación basada en Spring o Prime Faces . Spring Mobile vale la pena mirar. Prime Faces realmente implementa jQuery Mobile y es capaz de usar Theme Roller.

En general, realmente no importa qué marco de backend (si hay alguno) que utilice siempre y cuando esté presionando un buen marcado. Al navegador no le importa y lo único que le importa al usuario es una buena experiencia. Por lo tanto, elija lo que hará felices a sus desarrolladores por el backend siempre que no se interponga en el camino.

En cuanto a los frameworks frontales, sí, su popularidad va en aumento porque tienden a estandarizar algunas de las mejores prácticas en dispositivos móviles. Hay muchas comparaciones de jQuery Mobile vs Sencha vs jQTouch. Los dejo para que descubran cuál es la mejor opción para su proyecto, pero sin duda usarían jQuery Mobile o Sencha porque la comunidad de soporte que los rodea es enorme y es menos probable que se parezcan a los muchos sitios móviles domésticos que intenté hacerlo desde cero cuando no tenían la experiencia para llevarlo a cabo. Es triste. Mi recomendación personal es jQuery Mobile porque cubre una amplia gama de dispositivos y (siempre y cuando se adhiera al modelo estándar página por página) se degradarán con gracia incluso para los teléfonos más llamativos y seguirán siendo funcionales, pero se verán increíbles en los teléfonos inteligentes.

A su pregunta de simplemente usar un diseño RESTful con JavaScript cargando todo y administrando el estado. Hay muchos que lo están haciendo y sin duda es una experiencia rápida, pero limitará instantáneamente quién puede usarlo para las personas que los navegadores móviles admiten un buen JavaScript. Solo mirará compatible con iOS, Android 2.2 o superior, BlackBerry 6 o superior y Windows Phone 7 o superior. Todos los demás probablemente tendrán dificultades significativas para ver su sitio. Considere detenidamente a su audiencia antes de pasar a una implementación como esa. Si su sitio no funciona sin JavaScript y sus clientes principales están en el mundo corporativo ... lo que sucede cuando la última conferencia de Black Hat expone una debilidad en los teléfonos de la compañía y por mitigación conservadora de riesgos (paranoia), empujan una política de seguridad a todos los teléfonos que deshabilitan JavaScript. Este tipo de cosas sucede todo el tiempo. Por lo tanto, considera tu audiencia.