¿Es efectivo tener un back-end y front-end separados?

La respuesta de Titus Wiguno es bastante acertada, también me gustaría agregar que, en términos de escalabilidad futura, probablemente sería una buena idea separar el back-end y el front-end. IE, si se está comunicando con el back-end a través de API, entonces sería más fácil y menos lento escalar su aplicación a diferentes plataformas móviles.

Depende de lo que quieras decir con “efectivo”. En términos de desarrollo y costo, ciertamente no es “efectivo”. Probablemente duplicaría el costo (es más complicado construir una aplicación HTML que se conecte al backend a través de API; y lo más probable es que requiera al menos 2 equipos diferentes para desarrollarse (la depuración de la aplicación frontend es otro monstruo para la aplicación backend).

En términos de tecnicismo, diría que es preferible dividir el desarrollo de estos dos. Es más claro porque podría saber qué parte se comporta mal: los datos (back-end) o la presentación (frontend).

Además, en términos de rendimiento, diría que también es preferible dividir el desarrollo. Separar los servidores también ayudaría al rendimiento (aunque NO es obligatorio). El “servidor” frontend solo servirá archivos estáticos, por lo que la presentación / IU llegará más rápido y parecerá más receptivo a los usuarios finales. Y también facilitará el “servidor” del servidor al servir menos datos.

Estás mezclando un poco las cosas, pero déjame aclararte algo.

El front-end se puede servir a través de:

1. Representación dinámica del lado del servidor, (mire los tipos MVC de framewoks / arquitecturas): antigua forma de hacer aplicaciones web
2. aplicación estática de una sola página (ng, react, vue y similares) entregada desde su servidor o un CDN, respaldada por su API. – nueva forma de aplicaciones web progresivas

Tenga en cuenta que un sistema separado no tiene que ser 2 servidores. Puede servir partes integradas de front-end (HTML, css, js) desde una ruta en su servidor.

Hola,

Es aconsejable separar el back-end y el front-end. Además de un código más consistente, esta funcionalidad le permite escribir código con más profundidad y alcance. Cuando sus desarrolladores escupen código en múltiples repositorios, puede medirlos de forma independiente. Por ejemplo, puede volcar el código del cliente en un CDN mientras hace muchos servidores AWS para el backend. Esta flexibilidad en el escalado puede ahorrar dinero en alojamiento, costos de hardware y aumenta su capacidad de modificar la configuración a medida que crece su base de usuarios.

Además, varias personas están trabajando en los repositorios discretos, que es una buena manera de tener un desarrollador trabajando en la API mientras otro está trabajando en el cliente, es decir, si han acordado la salida JSON.

Espero que haya encontrado esta información útil para su propio proceso de programación.

Desarrollo web Aplicaciones web Desarrollo de sitios web personalizados Empresa | Servicios de desarrollo web EE.UU.

Si, se recomienda. Pero depende en gran medida de la situación y el tipo de público al que se dirige. Si está creando un sistema web al que accederán diferentes personas en diferentes dispositivos, es posible que tenga problemas cuando la gente empiece a quejarse de que su obra maestra es inútil solo porque están utilizando Opera Mini y similares. Sin embargo, si sus usuarios objetivo son conocidos, digamos que está creando un sistema de administración, es bueno separar el front-end y el back-end. Hace la vida más fácil.