¿Es un diseño normal desacoplar completamente las aplicaciones web de back-end y frontend y permitir que se comuniquen con la API REST (JSON)?

Estoy creando una nueva aplicación web comercial y quiero lograr:

• Utiliza las mejores tecnologías de sus respectivos reinos. Quiero un marco de backend confiable con ORM sólido. Y quiero el marco SPA (aplicación de una sola página) más avanzado con el uso de las funciones HTML y Javascript más actualizadas para la aplicación frontend
• Exponga entidades de back-end y servicios empresariales para el uso desde diferentes tipos de aplicaciones, por ejemplo, aplicaciones web, dispositivos móviles (Android) y posiblemente otros tipos (dispositivos inteligentes, etc.)

Entonces, para satisfacer ambos requisitos, me inclino a separar completamente mi aplicación en aplicaciones de back-end y frontend y organizar la comunicación entre ellas utilizando REST API (JSON). ¿Es este un enfoque sólido?

Dicha separación no es una solución de diseño obvia, porque muchas tecnologías de aplicaciones web tienen capas de vista integradas donde la aplicación del lado del servidor controla más o menos la generación de la vista y maneja parcialmente las respuestas de la vista (por ejemplo, SpringMVC con capa de vista, PHP Yii con vista capa, Java JSF / Facelets guarda completamente el estado de sus componentes en el servidor). Entonces, hay muchas tecnologías que proponen un acoplamiento más fuerte y prometen un tiempo de desarrollo más rápido y un recorrido de ruta más estándar. Entonces, debo ser cauteloso al comenzar a usar tecnologías de una manera que no se usa ampliamente.

Según tengo entendido, la interfaz de SPA completamente separada generalmente surge de la necesidad de usar API de terceros. ¿Pero es ese diseño de sonido de desacoplamiento cuando una compañía desarrolla tanto el backend como el frontend?

Mi elección de tecnologías actualmente es Java / Spring backend y Angular2 / Web Components / Polymer para frontend, si se me permite decir esto. Pero eso es irrelevante para esta pregunta, porque esta pregunta es sobre diseño general y no sobre la elección de tecnologías concretas.

¿Es un diseño normal desacoplar completamente las aplicaciones web de back-end y frontend y permitir que se comuniquen con la API REST (JSON)?

Si es normal. Pero es normal solo si necesita tener ese tipo de separación y no está forzando esta configuración en su aplicación general.

Un SPA viene con algunos problemas asociados con él. Aquí hay algunos que aparecen en mi mente ahora:

• es principalmente JavaScript. Un error en una sección de su aplicación podría impedir que otras secciones de la aplicación funcionen debido a ese error de Javascript. Con las páginas servidas desde el servidor (SpringMVC, PHP, etc.) vuelve a cargar una sección nueva;
• CORS . No necesariamente obligatorio, pero a menudo el back-end está en un nombre de dominio diferente al front-end. Así que ahora tienes que lidiar con los problemas de seguridad del navegador;
• SEO . ¿Necesitas esto? ¿Tu sitio es público? Google puede entender Javascript e intentar darle sentido a su sitio, pero básicamente le da el control a un bot y espera lo mejor. Recuperar el control puede significar tener que confiar en otras herramientas como PhantomJS .
• aplicación de front-end separada significa proyectos separados, tuberías de implementación, herramientas adicionales, etc.
• la seguridad es más difícil de hacer cuando todo el código está en el cliente;

Claro, también hay ventajas de SPA:

• interactúe completamente en el front-end con el usuario y solo cargue datos según sea necesario desde el servidor. Por lo tanto, mejor capacidad de respuesta y experiencia del usuario;
• dependiendo de la aplicación, algunos procesamientos realizados en el cliente significan que le ahorra al servidor esos cálculos.
• tener una mejor flexibilidad para evolucionar el back-end y el front-end (puede hacerlo por separado);
• si su back-end es esencialmente una API, puede tener otros clientes delante como aplicaciones nativas de Android / iPhone;
• la separación podría facilitar a los desarrolladores front-end hacer CSS / HTML sin necesidad de tener una aplicación de servidor ejecutándose en su máquina.

Entonces, la cosa es que hay ventajas y desventajas para ambos enfoques (SPA vs páginas del servidor). Dedique un tiempo a investigar ambas opciones y luego elija en función de su situación.

La respuesta a tu pregunta es simple. Sí. Lo que propones es un enfoque sólido . Pero entonces, lo que creo que quiere preguntar es si es un mejor enfoque, y desafortunadamente, ninguno de nosotros puede responder eso por usted. Los factores involucrados abarcan muchas facetas que, sin divulgar todo sobre su organización y los requisitos del producto, no se puede llegar a una conclusión real. Creo que ya sabes qué hacer de todos modos.

Normal con advertencias.

Los marcos de JavaScript de front-end están limitados en lo que pueden hacer. Si crea apis sin formato para que las utilicen varias aplicaciones, por lo general requieren un procesamiento del lado del servidor de las llamadas de api sin formato en modelos de vista que funcionan con esa aplicación en particular.

Por lo tanto, una arquitectura 'normal' podría ser:

database
business logic services (dll)
api exposing business logic
server side website exposing viewmodels and functionality via json rest endpoints
client side javascript implementing ui

Ahora, si solo tiene una aplicación web, puede cortar la capa 'api expone la lógica de negocios' y simplemente hacer que el código web del lado del servidor llame a la lógica de negocios directamente.

Debido a que ha separado la lógica de negocios en su propia biblioteca, todavía está desacoplada de la lógica de la interfaz de usuario y siempre puede agregar una capa de servicio más adelante.

De manera similar, debido a que el código del lado del servidor llama al servicio de API, no está limitado la comunicación http. (aunque esto es bastante universal ahora)

Además, hacer que JavaScript llame al mismo host desde el que se sirve significa que no tiene que andar con cors