¿Por qué el desarrollo de proyectos web debería adoptar el modelo de separación de front-end y back-end?

El front-end y el back-end deben desarrollarse de forma independiente, colocarse en dos servidores diferentes y deben implementarse de forma independiente. Se necesitan dos proyectos diferentes, dos bibliotecas de códigos diferentes, diferentes desarrolladores e ingenieros de front-end y back-end. Para trabajar en la interfaz interactiva, el desarrollo sincrónico solo se puede lograr cuando se llega a un acuerdo. Después del desarrollo, se requiere una implementación independiente. El front-end llama a la API llamada por el back-end a través de la interfaz. estilo de página y el análisis y representación de datos dinámicos, mientras que el back-end se centra en una lógica empresarial específica. El front-end solo necesita centrarse en el estilo de la página y el análisis y presentación dinámicos de datos, mientras que el back-end se centra en una lógica empresarial específica. Los beneficios específicos son los siguientes:

1. Liberar completamente el front-end

El front-end ya no necesita proporcionar plantillas al back-end ni incrustar contenido del back-end en el html generado por el front-end

2. Mejorar la eficiencia y hacer más clara la división del trabajo

El flujo de trabajo de separación del front-end y back-end permite que el front-end centrarse solo en las cosas del front-end y el back-end solo centrarse en el trabajo de back-end, y ambos se pueden desarrollar al mismo tiempo. Al mismo tiempo, cuando el backend no tiene tiempo para proporcionar interfaces, el front-end puede escribir los datos primero o llamar al archivo json local. Las adiciones de página y los cambios de enrutamiento no necesitan molestar al backend, lo que hace que el desarrollo sea más flexible.

3. Mejora del rendimiento local

Al configurar el enrutamiento front-end, podemos cargar la página bajo demanda sin cargar todos los recursos del sitio web desde la página de inicio y el servidor. Ya no es necesario analizar las páginas frontales y se han mejorado la interacción de la página y la experiencia del usuario.

4. Reducir los costos de mantenimiento

A través del marco principal MVC de front-end, podemos localizar y descubrir problemas rápidamente. Cuando ocurren problemas en el cliente, ya no necesitamos el back-end. personal para participar y depurar, y el código será reelaborado. Mejoras en la estructura y la mantenibilidad.

5. Logre una alta cohesión y un bajo acoplamiento para reducir la concurrencia/presión de carga en los servidores back-end (aplicaciones).

6.

6. Incluso si el servicio de back-end se agota temporalmente o no funciona, aún se puede acceder a la página de inicio normalmente, pero los datos no estarán disponibles .

7. De esta manera, el back-end puede lograr mejor alta concurrencia, alta disponibilidad y alto rendimiento; el front-end puede lograr mejor el rendimiento de la página, la velocidad y fluidez, la compatibilidad, la experiencia del usuario, etc.

Mi comprensión de la separación de front-end y back-end es que el front-end necesita iniciar el servidor para reducir los costos de aprendizaje. Puede usar nodos, y el front-end también necesita un nombre de dominio.

Si está semi-separado, entonces el front-end debe proporcionar js. También he hecho esto para archivos (css, etc.) No hablaré sobre el uso de nodos para el front-end y el back-end. hay dos idiomas,

Si se desarrolla bajo un archivo de proyecto.

Si desarrolla bajo un archivo de proyecto, webpack lo empaquetará directamente en el directorio estático del lenguaje back-end.

Si hay dos proyectos, entonces la interfaz solo proporciona el archivo js (css) generado y git extrae el proyecto en segundo plano y lo arroja al directorio estático. Esto también implica problemas de control de versiones. Generaré un El archivo de configuración se lee directamente y el contenido es un nombre de archivo como xxx.hash.js, y luego document.wirte se escribe dinámicamente en js/css. css

No es necesario importar dinámicamente el front-end desde el servidor. Utiliza directamente el complemento HTML para generar archivos para controlar mejor la versión.

Semiseparación. También hay un problema, como el isomorfismo de la página de inicio. Si se cambia El archivo xxx.blade.php, los archivos PHP que contiene, incluido el proxy inverso de nginx y el caché SSL, son todos muy problemáticos.

Pero este dominio cruzado es un poco incierto. Hasta ahora, mi backend es **, así que no puedo decir nada.

Alibaba Cloud es muy barato. el costo en términos de mano de obra, será muy costoso

La energía de una persona es limitada y la separación del front-end y back-end nos permitirá centrarnos más en los puntos técnicos que queremos centrarse en. Como dice el refrán, hay especializaciones en la industria del arte: la llamada industria de "habilidades" tiene especialización ".

Por ejemplo, nuestra separación de backend, frontend y backend nos ayuda a centrarnos en los conceptos básicos de Java, patrones de diseño, principios de jvm, principios y código fuente de Spring Springmvc, Linux, mecanismos de bloqueo y aislamiento de transacciones de MySQL, mongodb, http. /tcp, subprocesos múltiples, arquitectura distribuida (dubbo, dubbox, spring cloud), arquitectura informática elástica, etc.

El front-end también puede centrarse en la pantalla del front-end.

En términos generales, las ventajas de separar los extremos delantero y trasero superan las desventajas. Esta es también la razón por la que jsp se usa cada vez menos.

Dos puntos adicionales

1. La cantidad de datos solicitados cada vez se vuelve menor, lo que también significa que el tiempo de respuesta se acorta.

2. No todas las aplicaciones adoptan el método más apropiado para separar el front-end y el back-end. Es necesario juzgarlo de manera integral en función del tamaño y la duración de la aplicación.

3.