Acerca de la separación de front-end y back-end
Existe un malentendido sobre la separación de front-end y back-end, es decir, mucha gente afirma: Nos hemos separado hace mucho tiempo, todo AJAX, solo usamos Angular o algo así.
Esta afirmación es inapropiada, por ejemplo, alguien preguntó "¿Cómo solucionar el problema de las aves que ponen huevos junto a las plantas acuáticas?", pero en realidad crían patos, pero la respuesta es que soy un criador de pollos. , entonces mi respuesta es "No me dejes ir al agua". Obviamente, esta no es la idea correcta.
La separación de front-end y back-end mencionada en la industria en los últimos dos años se limita a sistemas orientados a visualización (reemplazados por A), en lugar de proyectos web de tipo aplicación y administración (reemplazados con B). En proyectos de tipo B, el front-end y el back-end están naturalmente separados, excepto por un pequeño número de desarrolladores de back-end, básicamente todos tienen la misma comprensión de esto. Las personas que respondieron así en el párrafo anterior generalmente solo trabajan en proyectos de tipo B. En proyectos de tipo B, la separación entre front-end y back-end es de conocimiento común y no es necesario discutirla.
Entonces, el problema restante es discutir la separación del front-end y back-end para proyectos Tipo A. El núcleo de este problema es dónde se combina la plantilla con los datos y quién tiene control sobre la plantilla. Después de dos años de discusión, básicamente el entendimiento más común al que podemos llegar es que las plantillas deben ser controladas por el personal de front-end. Las razones principales son dos:
-Optimización del rendimiento (especialmente la gestión de recursos externos). y publicación, solicitud de fusión, etc.)
-Colaboración fluida (problemas como reelaboración de fragmentos de interfaz que han formado plantillas)
Entonces, ¿dónde se debe combinar la plantilla con los datos? ?
Este problema es bastante problemático. Algunas personas intentan usar plantillas js como proyectos de Clase B y luego ejecutarlas en el lado del navegador. Hay algunos problemas, como SEO poco amigable y el rendimiento de la primera pantalla no es suficiente. Especialmente para los sitios web de comercio electrónico con una gran cantidad de DOM en la página de inicio, la brecha es obvia.
Así que todavía tenemos que poner la plantilla principal en el servidor para su ejecución. En este proceso, Alibaba hizo algunos intentos, es decir, introdujo la capa de Nodo, donde se sintetizan la plantilla y los datos, y luego el navegador obtiene el HTML generado, pero no todo el HTML se genera de esta manera. Todavía habrá algo de contenido. que espera hasta que llega al navegador y luego se carga y genera usando js.
Así que esta definitivamente será una solución híbrida. Hay dos plantillas en el mismo sistema, una se ejecuta en el servidor y la otra se ejecuta en el navegador, complementándose entre sí.
En cuanto a si la capa intermedia en esta solución debe ser un nodo, creo que no importa, siempre que se pueda usar para proyectos web normales. Esto todavía depende de la dirección de acumulación de tecnología. Por supuesto, node
Hay algunas ventajas al hacer esto, como la facilidad de uso del idioma para el personal de front-end, la versatilidad de las plantillas de front-end y back-end, etc., pero estos son detalles, y la atención se centra todavía en el plan y el proceso generales.
En este momento, vuelva a mirar la oración de su pregunta:
>La separación del front-end y el back-end significa que el front-end y el back-end solo se comunican a través de JSON, y la componenteización y La ingeniería no requiere dependencias para implementar.
Creo que su limitación en el front-end y back-end aquí se basa en el navegador, pero de hecho, en proyectos de Clase A, el límite entre el front-end y el back-end debe extenderse a la capa de plantilla del lado del servidor, que se encuentra en esta capa. Aquí, los datos de varias fuentes se integran en la plantilla. Es posible que estos datos no estén en formato JSON, pero pueden existir en JSON, XML, binario específico, etc.
El tema de la componenteización es aún más complicado en la forma organizativa actual, es difícil decir qué es exactamente un componente. ¿Es una plantilla para un determinado producto? ¿Son datos? ¿Es una combinación de datos y plantillas? Ninguna respuesta. Aquí, me gustaría expresar mi opinión: en la parte frontal de proyectos como el comercio electrónico, básicamente no existe el concepto de componentes, ni siquiera el valor de la componenteización, porque hay muy pocas cosas reutilizables y no es fácil de extraer. La mayoría de las cosas son plantillas de interfaz sin lógica.
Recientemente, la popularidad de ReactJS ha generado el concepto de isomórfico. Esta es una exploración muy significativa, pero aún se desconoce si puede resolver este tipo de problema. mejor solución complementaria para proyectos de Categoría B, pero actualmente carece de usabilidad para proyectos de Categoría A, porque en los proyectos de Categoría A, no hay muchos cambios DOM durante el tiempo de ejecución, y la mayoría de ellos son cambios en toda la pieza de esta solución. Se usa para resolverlo. Se siente como matar un pollo con un cuchillo.
En cuanto a la componenteización de proyectos de Clase B, mi serie anterior sin terminar trataba sobre eso, pero después de pensarlo durante más de un año, siento que necesito escribir otro artículo. Gracias por recordarme tu pregunta, la escribiré aquí.