En React, las aplicaciones isomórficas se refieren a aplicaciones que comparten código completo o parcial entre el cliente y el servidor, y también pueden denominarse aplicaciones JavaScript universales que no requieren la representación del contenido en el lado del navegador, pero logran un equilibrio entre el lado del servidor y el lado del servidor. renderizado en el lado del navegador, genera contenido de renderizado en el servidor y permite a los usuarios ver páginas con información lo antes posible.
El entorno operativo de este tutorial: sistema Windows 10, versión de reacción 17.0.1, computadora Dell G3.
Las aplicaciones isomórficas, también conocidas como aplicaciones JavaScript universales, se refieren a aplicaciones que comparten total (o parcialmente) código entre el cliente y el servidor. Al ejecutar el código JavaScript de la aplicación en el lado del servidor, la página se puede rellenar previamente con contenido antes de enviarla al navegador, de modo que los usuarios puedan ver el contenido incluso antes de que se ejecute el JavaScript del navegador. Cuando se ejecuta JavaScript local, se hará cargo de las operaciones de navegación e interacción posteriores, lo que permitirá a los usuarios obtener una experiencia interactiva fluida en aplicaciones de una sola página a través de una carga inicial rápida y la representación de páginas del lado del servidor.
¿Qué es el isomorfismo?
Con el repentino aumento de Node.js, el desarrollo front-end y back-end tiene la base de un lenguaje de programación estandarizado. Las plantillas de página, los mecanismos de dependencia de terceros, etc., tienen oportunidades para lograr la unificación del front-end y el back-end. -fin. React fue el primero en liderar esta tendencia y el concepto de isomorfismo se ha extendido más ampliamente.
Lo que los lectores deben comprender es que las aplicaciones isomórficas no requieren la representación del contenido en el lado del navegador, sino que logran un equilibrio entre la representación del lado del servidor y del lado del navegador. Entonces, ¿cómo entender este equilibrio?
Genere contenido de renderizado en el servidor para que los usuarios puedan ver páginas informativas lo antes posible. Además del contenido estático puro, una aplicación completa también incluye varias respuestas a eventos, interacciones del usuario, etc. Esto significa que los scripts de JavaScript deben ejecutarse en el lado del navegador para completar trabajos como vincular eventos y manejar interacciones asincrónicas.
Desde la perspectiva del rendimiento y la experiencia del usuario, la representación del lado del servidor debe expresar la información más importante, central y básica de la página, mientras que el lado del navegador necesita completar la representación de la página, el enlace de eventos y otras funciones mejoradas para la interacción. El llamado isomorfismo significa que el front-end y el back-end comparten un conjunto de código o lógica. En este conjunto de código o lógica, la situación ideal es juzgar la estructura DOM existente y la estructura que se representará durante el proceso de renderizado posterior. el lado del navegador. ¿Es lo mismo? Si es así, la estructura DOM no se volverá a representar, solo se requiere el enlace de eventos.
Desde esta dimensión, el isomorfismo es diferente de la representación del lado del servidor. El isomorfismo se parece más a la intersección de la representación del lado del servidor y la representación del lado del navegador. Compensa las diferencias entre el lado del servidor y el lado del navegador, de modo que lo mismo. conjunto de código o La lógica se puede unificar. El núcleo del isomorfismo es "el mismo conjunto de códigos", que es otra dimensión separada de los ángulos en ambos extremos.
Ventajas y desventajas del isomorfismo
Las ventajas del isomorfismo son las siguientes:
Mejor rendimiento. El rendimiento aquí se refiere principalmente a una renderización más rápida, un tiempo de visualización en la primera pantalla más rápido, menos archivos y un tamaño de archivo más pequeño.
Soporte de optimización SEO. Después de recibir la solicitud, el servidor devolverá un documento HTML relativamente completo que contiene el contenido inicial, lo que es más propicio para que los rastreadores de los motores de búsqueda obtengan información y mejoren la clasificación de visualización de los resultados de búsqueda. Al mismo tiempo, tiempos de carga de páginas más rápidos también ayudarán a mejorar la clasificación de visualización de los resultados de búsqueda.
La implementación es más flexible. La representación del lado del servidor solo genera el contenido inicial de la página, y el navegador aún necesita realizar un trabajo de seguimiento para completar la presentación final de la página. De esta manera, la representación del lado del servidor y la representación del lado del navegador aún se pueden equilibrar y se puede lograr en gran medida la reutilización del código.
Más mantenible. Porque con la ayuda de bibliotecas como React, podemos lograr una amplia gama de reutilización de código, evitando la necesidad de que el servidor y el navegador mantengan dos conjuntos de código o lógica al mismo tiempo. Como resultado, el volumen total de código es menor y los costos de mantenimiento son menores.
Más amigable con los modelos de gama baja. Debido a que la representación inicial del contenido se completa en el lado del servidor, es más amigable para los modelos de gama baja y no provocará una pantalla blanca cuando se cargue la página.
Más amigable para entornos de red hostiles. En el método tradicional de separación de front-end y back-end, el contenido de la página se mostrará solo después de que se hayan descargado y ejecutado todos los scripts de JavaScript. Se ha experimentado una gran cantidad de solicitudes de red en el proceso. Sin duda, aumenta la dificultad de representar el contenido básico de la página. En este sentido, las aplicaciones isomórficas tienen claramente ventajas.
Mejor experiencia de usuario. Para equilibrar de manera más razonable el contenido de representación del lado del servidor y del lado del navegador, podemos diseñar las partes centrales importantes de la página para que se completen en el lado del servidor, mientras que las partes interactivas menos importantes pueden ser representadas por el navegador o después de la finalización. Se representa contenido más importante. La implementación mejorará enormemente la experiencia del usuario.
Las desventajas del isomorfismo son las siguientes:
La lógica de procesamiento del lado del servidor aumenta, aumentando la complejidad.
El servidor no puede reutilizar completamente el código del lado del navegador.
Se agregó tiempo TTFB (tiempo hasta el primer byte) en el lado del servidor. El tiempo TTFB se refiere al tiempo desde que el navegador inicia la solicitud de red inicial hasta que se recibe el primer byte del servidor. Contiene el tiempo de conexión TCP, el tiempo para enviar la solicitud HTTP y el tiempo para obtener el primer byte del mensaje de respuesta. Porque la adquisición de datos y la representación del contenido inicial de la página reducirán inevitablemente la velocidad de retorno del servidor.
Amplíe sus conocimientos:
Diseño de arquitectura front-end y back-end y conceptos de renderizado del lado del servidor
El concepto de renderizado o drop-in del lado del servidor se está volviendo cada vez más popular. Antes de comprender cómo implementar la representación del lado del servidor basada en React, es necesario que tengamos una comprensión general del "pasado y presente" de la representación del lado del servidor a nivel arquitectónico: por qué aparece tal concepto, qué problemas pueden surgir; se resuelve después de implementar este concepto de renderizado del lado del servidor y ¿Cuáles son las ventajas y desventajas de otros métodos?
La evolución de la tecnología de cooperación front-end y back-end.
En los primeros días del desarrollo web, el diseño de la arquitectura era simple y directo. Específicamente, la página era generada en el lado del servidor por JSP, PHP y otros ingenieros, y el navegador solo era responsable de mostrarla. En ese momento, el ingeniero de front-end solo necesitaba agregar algunos efectos interactivos dinámicos a la página estática, y rara vez involucraba lógica de datos, etc., mientras que el ingeniero de back-end era responsable del contenido de la página, es decir, cuando el usuario; solicitó la página, el back-end la procesó y devolvió la página estática completa. Estos procesos generalmente dependen de motores de plantillas para completarse. Entonces, en ese momento, ni siquiera había un puesto de ingeniero de front-end separado. Incluso si las hubiera, las deficiencias de este enfoque son obvias, como una división poco clara de responsabilidades entre el front-end y el back-end.
Si el personal de front-end desarrolla plantillas, el front-end dependerá en gran medida del entorno de back-end, lo que dificultará maximizar la eficiencia del desarrollo. Al mismo tiempo, el costo de la comunicación sobre los formatos de datos será relativamente alto. Además, dicho modelo arquitectónico tiene un espacio muy limitado para el desarrollo de tecnología front-end y el uso de capacidades del navegador.
Con el rápido desarrollo de la tecnología front-end, especialmente la aparición de tecnologías como AJAX y Node.js, ha surgido un modelo de arquitectura que separa el front-end y el back-end. En este modo, la división del trabajo entre el front-end y el back-end se vuelve muy clara, y el punto clave de colaboración en ambos extremos es la interfaz AJAX. Tomemos la página de acceso del usuario como ejemplo para comprender este modelo paso a paso, como se muestra en la siguiente figura.
