Introducción básica
Comencemos con un concepto importante "plantilla". En términos generales, una plantilla en la web es una página que puede generar un archivo después de completar los datos. Hablando estrictamente, el motor de plantilla debe usar archivos en un formato específico y los datos proporcionados para compilar y generar páginas. Las plantillas se dividen aproximadamente en plantillas frontales (como EJS) y plantillas de fondo (como Freemarker) compiladas en el navegador y el lado del servidor, respectivamente.
Dado que algunos estudiantes en el lugar no sabían mucho sobre Node.js, aquí están algunos de los conocimientos relevantes de Node.js. No hablaré sobre las definiciones de eventos, asíncronos, etc. en el sitio web oficial. Aquí tomo prestada una imagen de Pu Lingshu para explicar la estructura de Node.js. Si comprende Java, puede entenderlo como una versión JS de JVM. Los navegadores generalmente incluyen renderizadores y motores de guiones JS. Tomando el navegador Chrome como ejemplo, usan el renderizador del núcleo WebKit y el motor de script V8, mientras que Node.js usa el motor V8. En resumen, es un entorno JS que ejecuta, al igual que la herramienta de depuración F12 del navegador, pero Node.js no tiene DOM y BOM.
Esta imagen describe cierta información sobre Node.js, como NPM, el excelente administrador de paquetes, la comunidad CNODE y GitHub, que han promovido la prosperidad de Node.js hasta cierto punto y proporcionadas garantías técnicas.
Las grandes empresas suelen ser la veleta de la tecnología. Por ejemplo, Angular de Google y React de Facebook ahora son muy populares. Solo 3 grandes empresas se enumeran aquí como ejemplos. No hace falta decir que la arquitectura Midway de Taobao es, Pu Ling, el pionero de Node.js, proviene de Taobao. Qunar también ha desarrollado un marco técnico que debería llamarse "QTX". El equipo 75 liderado por Yueying lanzó un marco de servidor web basado en ES6/ES7 - ThinkJS. En ese momento, nuestro director técnico era muy optimista, pero debido a que no tuve tiempo de aprender ES6 y los complementos no eran lo suficientemente ricos, todavía elegí un expreso más maduro.
Volviendo al tema, esta tabla enumera tres métodos de desarrollo para la separación de los extremos frontales y traseros a los que he estado expuesto. La primera son las plantillas de lenguaje de backend más comunes que usan Java, que son amigables con SEO, y son mejores en la utilización de caché y reducen la carga de representación del navegador. El mayor problema es que el grado de acoplamiento de los archivos de plantilla es demasiado alto. Nadie quiere resolver el problema. El personal delantero no puede ver los datos, el personal de back-end no comprende la página, y los archivos de plantilla son como una papa caliente. El segundo es la solución de implementación actual del terminal móvil de nuestro proyecto, que utiliza el marco de angular (las instrucciones angulares pueden considerarse como plantillas front-end) y el servidor proxy inverso de Nginx para desacoplar completamente el front-end y el fondo, y solo interactúan con datos a través de AJAX. Esta solución es exactamente lo opuesto a las ventajas y desventajas de la primera. El rendimiento de las plantillas de front-end siempre es un problema, especialmente en dispositivos móviles, y más particularmente en dispositivos móviles de baja gama. El último es el nuevo proyecto que usa Node.js como servidor frontal, que divide las responsabilidades front-end del navegador al nivel de plantilla, resolviendo todos los problemas anteriores, pero de hecho hay nuevos problemas, y este problema se analizará más adelante.
Por supuesto, el desarrollo completo de la pila también es muy adecuado para pequeños proyectos. Para el desarrollo tradicional de JSP/PHP, el costo de comunicación del desarrollo completo de la pila es más bajo, y los desarrolladores pueden comprender fácilmente todo el módulo funcional, mejorando mejor el diseño del producto. Especialmente el desarrollo de la pila completa basado en el lenguaje JS: meteoritos y tecnología media que ahora están emergiendo hace que el desarrollo front-end y back-end se maneje directamente en un idioma. Con MongoDB, los datos del navegador a la base de datos se usan directamente sin escapar, y no hay necesidad de escribir SQL, lo que reduce en gran medida el costo de desarrollo.
Algunos complementos utilizados para construir el servidor Node.js esta vez. No es necesario presentar el famoso Express, el marco de servidor web ligero. También es una coincidencia usar el motor de plantilla de manillares, porque Express4 lo es por defecto. Manillars es digno de ser el motor de plantilla de la "lógica débil". Aboga por la reducción de la lógica de la plantilla e intenta usar solo variables y paginación. Basado en su concepto de diseño, solo he ampliado dos ayudantes. Artículo específico: https://yalishizhude.github.io/2016/01/22/handlebars/superagent todavía se usa debido a Express4. Debido a que su código de prueba usa SuperTest, SuperTest se basa en supergente, por lo que se usa supergente para reenviar e iniciar solicitudes. Superagente sigue siendo demasiado débil y no se puede establecer para conexiones largas. Todavía recomiendo el complemento de solicitud. No hay nada que presentar a Restfuleapi. El servidor front-end y el navegador, el servidor frontal y el servidor back-end usan este conjunto de especificaciones. Básicamente, la URL apunta a los recursos, agrega, elimina, modifica y verifica, y se expresa el método de solicitud específico, los códigos de estado representan resultados, etc. ~ Tool de empaque de trago, Webpack ha estado estudiando durante mucho tiempo y descubrió que cada página agregada requiere modificación del archivo de configuración. Esto es demasiado doloroso, así que me di por vencido.
Proceso de desarrollo
Si este intercambio habla principalmente sobre cómo usar Node.js como un servidor frontal para lograr la separación frontal, entonces no hay nada que decir, solo mire el artículo en Taobao UED. El mayor problema con la separación de los extremos frontales y traseros es que plantea los costos de comunicación, específicamente la definición y la depuración de interfaces. En el proceso de desarrollo tradicional en la figura anterior, la definición de la interfaz se colocará en el servidor de interfaz, y luego los extremos delanteros y posteriores realizarán la depuración local en función de los datos de fraude del documento de la interfaz y luego realizarán depuración conjunta. Este enlace es cuando los extremos delanteros y traseros comienzan a luchar. Este parámetro es incorrecto y el valor de retorno es incorrecto. En resumen, es una pérdida de tiempo. A continuación, veamos cómo se resuelve este problema en nuestro proyecto ~
Siempre ha existido el problema del deshilachado de la interfaz en los extremos delanteros y traseros. Como conservador, creo en el desarrollo iterativo, por lo que el primer paso es agregar un servidor simulado. La magia de este servidor es que genera automáticamente datos falsos basados en el documento de la interfaz, implementando la interfaz, a saber, la API y los estudiantes front-end ya no tienen que escribir los datos hasta la muerte para las pruebas. No hay forma, ¿quién dijo que soy un desarrollador frontal? En primer lugar, pienso en mi propia gente. Jeje ~ Por supuesto, esto solo es beneficioso para el desarrollo frontal hasta cierto punto. También habrá problemas cuando las interfaces y documentos del back-end sean inconsistentes y están conectados. ¿Qué hacer?
Accidentalmente vi un artículo de Lao Ma en el blog de The Blade Master, que habla específicamente sobre la separación de los extremos delanteros y traseros. Uno de los conceptos importantes es las pruebas de contrato, también llamadas pruebas bilaterales. El concepto central es resolver el problema de la depuración articular remota. Verifique los parámetros de los extremos frontales y traseros y requiera que todos se desarrollen de acuerdo con el documento de la interfaz. Inspirada por él, se agregó la regla JSON-Schema para realizar la verificación de parámetros de las solicitudes HTTP, y quien no siga las reglas lo cambiará.
Esta RedMine es nuestro primer administrador de documentos de interfaz y no tiene otra función, excepto las funciones de grabación y visualización.
Swagger se conoce como el servidor de documentos de interfaz más popular del mundo. Tiene una interfaz hermosa y muchos complementos. Puede generar directamente el código de prueba para los idiomas de fondo. Sin embargo, nunca lo entendí al desplegarlo, y el formato YAML no es tan bueno como JSON, así que me di por vencido.
Este es el servidor de documentos y el servidor simulado utilizado en nuestro proyecto, el servidor implementado en función de la tecnología media y las funciones básicas:
Usando el complemento MOCKJS, los datos aleatorios se pueden generar dinámicamente para realizar pruebas de interfaz de suma de comprobación en los parámetros de interfaz basados en JSON-Schema, y se puede guardar el estado de la prueba y el tiempo de respuesta de la interfaz. El simple editor JSON tiene la función de verificación de inicio de sesión, y la depuración de la interfaz se puede realizar después de iniciar sesión. El servidor Mock responde a la solicitud de acuerdo con el servidor API, y se actualizará automáticamente cuando la interfaz se actualice.
Algunas preguntas
Node.js son las alas de los ingenieros front-end, y ¿debería convertirme en un ángel o un demonio con alas? Esto depende de si los problemas causados por el uso se pueden resolver.
En primer lugar, la carga de trabajo en la parte delantera sin duda aumentará, pero el costo de comunicación se reducirá. La estabilidad del servidor de Node.js Single Subtre no es lo suficientemente buena, pero la robustez del código y el registro perfecto se pueden evitar de manera efectiva. Llamar de vuelta. Hay demasiadas soluciones a este problema, incluido el módulo Q/Async de node.js y ES6/ES7. Node.js depuración. Aunque siempre he rechazado IDE, debo admitir que Webstorm es realmente muy conveniente para la depuración. El inspector de nodos que uso también es bastante buena, la interfaz es similar a la herramienta de desarrollador de Chrome y parece bastante familiar.
Si es un programador de backend, es más probable que sea acomodador Node.js. El trabajo de integración de la interfaz se entrega al servidor frontal para su procesamiento, y el grado de acoplamiento con el front-end se reduce considerablemente, y la carga de trabajo y la eficiencia de trabajo se reducen.
Hay dos puntos para experimentar
Aunque el uso de Node.js tiene un cierto costo de aprendizaje, todavía es muy amigable para los desarrolladores front-end. Además, si Node.js se usa en el frente, tanto el contenido técnico como la carga de trabajo mejorará, lo que mejorará la importancia del trabajo. Solo cuando los desarrolladores actuales pueden crear más valor son elegibles para exigir salarios más altos. Se recomienda hacer menos sugerencias y dar más planes de factibilidad en el trabajo, y realizar una investigación previa técnica en lugar de escribir un simple helloworld.
Resumir
Algunas personas pueden decir que el conjunto de cosas que introdujo es tan complicado y es demasiado problemático de usar, por lo que es mejor comunicarse cara a cara. Para tales dudas, solo puedo usar un ejemplo mencionado por el ingeniero de interfaz de usuario senior de Tencent, Yu Guo, en "autocultivo de ingenieros de pila completa". Una vez, cuando la persona front-end a cargo de una pequeña empresa en el teléfono le preguntó cómo administrar el código, la otra parte dijo que usaría FTP para cargarlo directamente, y se quejó de que sus subordinados siempre actualizaron el código incorrecto. También le preguntó por qué no usó SVN o GIT. Dijo que sería más fácil actualizar manualmente. La verdad de esta historia es mi respuesta a la pregunta ~
Dirección de descarga de PPT