Prefacio
Para resolver los diversos problemas traídos por el modelo de desarrollo web tradicional, hemos hecho muchos intentos, pero debido a la brecha física entre los extremos delanteros y traseros, las soluciones que probamos son similares. Aprendiendo del dolor, hoy reconsideramos la definición de "delantero y trasero" e introducimos NodeJs, que es familiar para los estudiantes de front-end, tratando de explorar un nuevo modo de separación frontal.
Con el aumento de diferentes terminales (PAD/Mobile/PC), los desarrolladores tienen requisitos cada vez más altos. La capacidad de respuesta del lado del navegador puro ya no puede cumplir con los altos requisitos de la experiencia del usuario. A menudo necesitamos desarrollar versiones personalizadas para diferentes terminales. Para mejorar la eficiencia del desarrollo, la necesidad de la separación de los extremos frontales y traseros es cada vez más valorada. El back -end es responsable de las interfaces comerciales/de datos, el frente es responsable de la lógica de visualización/interacción, y podemos personalizar y desarrollar múltiples versiones de la misma interfaz de datos.
Este tema se ha discutido mucho recientemente, y algunos autobuses de Alibaba también están haciendo algunos intentos. Después de una larga discusión, nuestro equipo decidió explorar un conjunto de esquemas de separación front-end y back-end basado en NodeJs. Hubo algunos entendimientos y pensamientos cambiantes en el proceso. Lo grabé aquí. También espero que los estudiantes que vi participaron en la discusión y nos ayuden a mejorarla.
1. ¿Qué es la separación frontal?
Durante la discusión inicial dentro del grupo, descubrí que todos tienen una comprensión diferente de la separación frontal. Para garantizar que puedan discutir en el mismo canal, primero llegaremos a un acuerdo sobre qué es la "separación del extremo delantero".
Un ejemplo de separación frontal con la que todos están de acuerdo es SPA (aplicación de una sola página). Todos los datos de presentación utilizados son proporcionados por el backend a través de la interfaz asíncrona (AJAX/JSONP), y el front-end solo lo muestra.
En cierto sentido, SPA logra la separación frontal, pero hay dos problemas con este método:
Entre los servicios web, SPA representa una proporción muy pequeña. En muchos escenarios, también hay un modo híbrido síncrono/sincrónico + asincrónico, y el SPA no puede usarse como una solución general.
En el modelo actual de desarrollo de spa, la interfaz generalmente se proporciona de acuerdo con la lógica de presentación. A veces, para mejorar la eficiencia, el backend nos ayudará a manejar alguna lógica de presentación, lo que significa que el backend todavía está involucrado en el trabajo de la capa de vista, no en la separación real de los delanteros y los backends.
La separación frontal de estilo SPA se distingue de la capa física (piense que siempre que sea el cliente, el front-end y el back-end es el servidor). Esta clasificación ya no puede satisfacer nuestras necesidades de separación frontal. Creemos que solo dividiendo las responsabilidades podemos cumplir con nuestros escenarios de uso actuales:
Front-end: responsable de la vista y las capas del controlador.
Backend: solo responsable de la capa de modelo, procesamiento de negocios/datos, etc.
¿Por qué esta división de responsabilidades se discutirá más adelante?
2. ¿Por qué deberíamos separar los extremos delanteros y traseros?
Con respecto a este tema, el artículo de Yu Bo lo explica de manera muy integral en la evolución del modelo de I + D web. Lo revisemos brevemente:
2.1 Escenarios aplicables para los modelos de desarrollo existentes
Los modelos de desarrollo mencionados por Yu Bo tienen sus propios escenarios aplicables, y ninguno de ellos reemplaza por completo al otro.
Por ejemplo, para MVC, que se basa principalmente en el backend, es muy eficiente realizar un negocio de visualización sincrónico, pero al encontrar una página sincrónica y asincrónica, será más problemático comunicarse con el desarrollo de backend.
Ajax es el principal modelo de desarrollo de spa, que es más adecuado para desarrollar escenarios de tipo aplicaciones, pero solo es adecuado para hacer aplicaciones, porque el SEO y otros problemas son difíciles de resolver. Para muchos tipos de sistemas, este método de desarrollo también es demasiado pesado.
2.2 Las responsabilidades delanteras y traseras no están claras
En sistemas con lógica comercial compleja, tenemos más miedo de mantener el código mezclado con los extremos delanteros y traseros. Debido a que no hay restricción, el código de otras capas de MVC puede aparecer en cada capa. Con el tiempo, no hay mantenimiento en absoluto.
Aunque la separación de los extremos delanteros y traseros no puede resolver por completo este problema, puede aliviarse enormemente. Porque está garantizado desde un nivel físico que no puedes hacer esto.
2.3 Problemas de eficiencia de desarrollo
La web de Taobao se basa básicamente en el MVC Framework WebX, y la arquitectura determina que el front-end solo puede confiar en el back-end.
Por lo tanto, nuestro modelo de desarrollo sigue siendo que el front-end escribe demostraciones estáticas y el back-end las traduce en plantillas de VM. No hablaré sobre el problema con este modelo, y he sido criticado durante mucho tiempo.
También es doloroso desarrollarse directamente en función del entorno de fondo, y es problemático configurar, instalar y usar. Para resolver este problema, inventamos varias herramientas, como VMarket, pero el front-end todavía tiene que escribir máquinas virtuales y confiar en datos de back-end, por lo que la eficiencia aún no es alta.
Además, el backend no puede deshacerse del fuerte enfoque en la exhibición y, por lo tanto, centrarse en el desarrollo de la capa lógica de negocios.
2.4 Limitaciones en el rendimiento frontal
Si la optimización del rendimiento solo se realiza en la parte delantera, a menudo necesitamos una cooperación de backend para crear chispas. Sin embargo, debido a las limitaciones del marco de backend, es difícil para nosotros usar Comet, BigPipe y otras soluciones técnicas para optimizar el rendimiento.
Para resolver algunos de los problemas mencionados anteriormente, hemos realizado muchos intentos y desarrollado varias herramientas, pero nunca ha habido mucha mejora, principalmente porque solo podemos usar la pequeña pieza de espacio dividida por nosotros en el backend. Solo separando verdaderamente los extremos delanteros y traseros podemos resolver completamente los problemas anteriores.
3. ¿Cómo separar los extremos delanteros y traseros?
¿Cómo separar los extremos delanteros y traseros? De hecho, hay una respuesta en la primera sección:
Front-end: responsable de la vista y las capas del controlador.
Backend: responsable de la capa de modelo, procesamiento de negocios/datos, etc.
Imagínese, si el front-end domina al controlador, podemos hacer un diseño de URL, podemos decidir si sincronizar la representación en el servidor de acuerdo con la escena o emitir datos JSON basados en los datos de la capa de vista, y también podemos hacer fácilmente BigPipe, Comet, Socket, etc. Según las necesidades de la capa de presentación. Es completamente el método de uso determinado por los requisitos.
3.1 Desarrollo de "pila completa" basado en NodeJS
Si desea implementar la capas de la figura anterior, inevitablemente necesitará un servicio web para ayudarnos a darnos cuenta de lo que hacemos antes y después del backend, por lo que existe el título "Desarrollo completo de la pila basado en NodeJ"
Esta imagen parece simple y fácil de entender, pero no la ha intentado y habrá muchas preguntas.
En el modo SPA, el backend ha proporcionado la interfaz de datos requerida, y el frontend de la vista ya se puede controlar. ¿Por qué agregar la capa NodeJS?
¿Qué tal agregar una capa más?
¿Agregar una capa más aumentará la carga de trabajo del front-end?
Agregar una capa más conducirá a otra capa de riesgo. ¿Cómo romperlo?
Nodejs puede hacer cualquier cosa, ¿por qué todavía necesitas Java?
No es fácil explicar estos problemas claramente. Déjame hablar sobre mi proceso de comprensión a continuación.
3.2 ¿Por qué agregar una capa de NodeJS?
En esta etapa, desarrollamos principalmente el modelo MVC de backend. Este modelo dificulta seriamente la eficiencia del desarrollo frontal y evita que el back-end se centre en el desarrollo empresarial.
La solución es habilitar el front-end para controlar la capa del controlador, pero es difícil hacerlo bajo el sistema tecnológico existente, porque es imposible dejar que todos los frontales aprendan Java, instalar el entorno de desarrollo de back-end y escribir máquinas virtuales.
NodeJs puede resolver este problema muy bien. Podemos hacer lo que el desarrollo nos ayudó a hacer antes, y todo parece tan natural.
3.3 Problemas de rendimiento
La capas implica la comunicación entre cada capa, y definitivamente habrá ciertas pérdidas de rendimiento. Sin embargo, la estratificación razonable puede hacer que las responsabilidades sean claras y colaborativas, lo que mejorará en gran medida la eficiencia del desarrollo. Las pérdidas causadas por la estratificación definitivamente serán compensadas en otros aspectos.
Además, una vez que decidimos atar, podemos minimizar las pérdidas optimizando los métodos de comunicación y los protocolos de comunicación.
Por ejemplo:
Después de que la página de detalles del bebé de Taobao es estática, todavía hay mucha información que debe obtenerse en tiempo real, como logística, promociones, etc. Debido a que esta información se encuentra en diferentes sistemas comerciales, el front-end necesita enviar 5 o 6 solicitudes asíncronas para rellenar estos contenidos.
Con NodeJs, el front-end puede proponer estas 5 solicitudes asíncronas en NodeJS, y puede hacer fácilmente BigPipe. Esta optimización puede mejorar mucho toda la eficiencia de representación.
Puede pensar que está bien enviar 5 o 6 solicitudes asincrónicas en la PC, pero en el lado inalámbrico, es muy costoso establecer una solicitud HTTP en el teléfono móvil del cliente. Con esta optimización, el rendimiento se mejora varias veces.
Los detalles de Taobao se basan en la optimización de NodeJS. Estamos en progreso. Después de que se lance, compartiré el proceso de optimización.
3.4 ¿Ha aumentado la carga de trabajo front-end?
En comparación con solo cortar páginas/demostraciones, debe ser un poco más, pero hay enlaces y comunicaciones en el modo actual. Este proceso lleva mucho tiempo, es propenso a los errores y es difícil de mantener.
Por lo tanto, aunque la carga de trabajo aumentará un poco, la eficiencia general del desarrollo mejorará enormemente.
Además, los costos de prueba se pueden ahorrar mucho. Las interfaces desarrolladas en el pasado están dirigidas a la capa de presentación, y es difícil escribir casos de prueba. Si se realiza la separación del extremo delantero y trasero, incluso la prueba se puede separar. Un grupo de personas se especializa en probar la interfaz y el otro grupo de personas se enfoca en probar la interfaz de usuario (esta parte del trabajo incluso puede ser reemplazada por herramientas).
3.5 ¿Cómo controlar los riesgos traídos al agregar la capa de nodo?
Con el uso a gran escala del nodo, los estudiantes del Sistema/Departamento de Operación y Mantenimiento/Seguridad definitivamente se unirán a la construcción de infraestructura. Nos ayudarán a mejorar posibles problemas en cada enlace y garantizar la estabilidad del departamento.
3.6 El nodo puede hacer cualquier cosa, ¿por qué todavía necesitas Java?
Nuestra intención original es separar los extremos delanteros y traseros. Si consideramos este problema, será un poco contrario a nuestra intención original. Incluso si usamos Node para reemplazar a Java, no podemos garantizar que no encontraremos ningún problema que encontremos hoy, como responsabilidades poco claras. Nuestro objetivo es desarrollar de manera en capas, personas profesionales y centrarnos en hacer cosas profesionales. La infraestructura basada en Java ya es muy poderosa y estable, y es más adecuada para hacer lo que ahora es arquitectura.
4. Separación frontal basada en nodos de Taobao
La imagen de arriba es lo que entiendo en la separación y capas front-end y de fondo de Taobao basadas en el nodo, así como el alcance de las responsabilidades del nodo. Una breve explicación:
El extremo superior es el servidor, que es lo que a menudo llamamos el backend. Para nosotros, el backend es una colección de interfaces, y el servidor proporciona varias interfaces para que lo usemos. Debido a que hay una capa de nodo, no hay necesidad de limitar qué forma de servicio es. Para el desarrollo de backend, solo usan interfaces que se preocupan por el código de negocios.
El servidor está debajo de la aplicación de nodo.
Hay una capa de proxy modelo en la aplicación de nodo que se comunica con el servidor. Esta capa se usa principalmente para suavizar la forma en que llamamos diferentes interfaces y encapsulamos algunos modelos necesarios por la capa de vista.
La capa de nodo también puede lograr fácilmente el VMCommon original, TMS (citando el sistema de administración de contenido Taobao) y otros requisitos.
Qué marco para usar para la capa de nodo depende del desarrollador para decidir. Sin embargo, se recomienda utilizar una combinación de Express + Xtemplate, que se puede usar para los extremos delanteros y traseros.
Todos deciden cómo usar el nodo, pero lo emocionante es que finalmente podemos usar el nodo para implementar fácilmente el método de salida que queremos: JSON/JSONP/RESTFUL/HTML/BIGPIPE/COMET/SOCKET/SINCRONOus y asíncrono. Se puede hacer lo que quiera, y se decide completamente en función de su escenario.
La capa del navegador no ha cambiado en nuestra arquitectura, y no queremos cambiar su comprensión previa del desarrollo en el navegador debido a la introducción del nodo.
La introducción del nodo es solo para entregar la parte de control frontal que debe ser controlada por el front-end.
Tenemos dos proyectos en desarrollo en este modelo. Aunque aún no se han lanzado, ya hemos probado la dulzura en términos de eficiencia del desarrollo y optimización del rendimiento.
5. ¿Qué más necesitamos hacer?
Integre el proceso de desarrollo de Node en el proceso SCM existente de Taobao.
Construcción de infraestructura, como Session, Logger y otros módulos generales.
Mejores prácticas de desarrollo
Historias de éxito en línea
La comprensión de todos del concepto de separación de los extremos delanteros y traseros del nodo
Seguridad
actuación
…
No habrá demasiada tecnología que necesite innovación e investigación, y ha habido mucha acumulación preparada. De hecho, la clave es la apertura de algunos procesos y la acumulación de soluciones generales. Creo que con más prácticas de proyectos, esta área se convertirá gradualmente en un proceso estable.
6. "Midway Island"
Aunque el modelo de "desarrollo completo basado en NodeJS" es emocionante, todavía hay mucho que hacer para transformar el desarrollo de pila completa basada en el nodo en algo que todos pueden aceptar. Nuestro proyecto en curso "Midway" es resolver este problema. Aunque no estamos mucho antes, ¡nos estamos acercando cada vez más a nuestro objetivo! !