¿Cómo evaluar la separación del front-end y back-end del marco Zhongdao de Taobao UED?

Laxantes.

1. Esta serie de artículos está bien escrita.

Quienes me conocen sabrán que rara vez doy críticas "muy buenas".

2. Esta serie de artículos y las prácticas detrás de ellos han restablecido la posición de liderazgo de Taobao en los estándares de ingeniería front-end.

Anteriormente, al menos desde una perspectiva externa, Taobao se había quedado atrás de Wolf y Penguin durante algún tiempo.

3. Esta serie de artículos y las prácticas detrás de ellos también demuestran la importancia de nodejs para el front-end, que no solo se refleja en la cadena de herramientas, sino también a nivel arquitectónico.

Tenga en cuenta que las opiniones de esta serie de artículos no son nuevas, pero creo que lograr este tipo de transformación en un producto de la escala de Taobao es muy icónico, porque Taobao ya es muy maduro.

4. Todavía hay mucho margen de mejora en detalles específicos, por ejemplo, el cuarto artículo de esta serie, "Reflexiones y prácticas sobre la separación de front-end y back-end (4)". , todavía existe en términos de defensa contra XSS. Algunas preguntas tradicionales. En este sentido, al participar en Hang JS, el autor se comunicó con un compañero de clase de Taobao Herman y no discutirá este tema en detalle. Debido a que se trata de un problema local, tiene poco impacto en la arquitectura general.

5. Tenga en cuenta que la evaluación anterior trata sobre la estructura, es decir, la idea. En cuanto a si se implementó bien o no, creo en sus propias palabras. Pero en lo que respecta al marco Midway en sí, dado que el autor no ha visto los documentos y códigos específicos, y su desarrollo es principalmente para satisfacer las necesidades de Taobao, es imposible juzgar si él o sus componentes específicos son adecuados y excelentes. en sentido general.

Respuesta de Xu Fei (19 votos):

Vi al Sr. He tomando medidas por la mañana, así que no pude evitar escribir un artículo para hablar sobre las consideraciones de un empresa como Suning en este sentido.

En los últimos dos años, he estado pensando en cómo mejorar el modelo de desarrollo del sistema front-end. El punto más básico es la separación del front-end y el back-end. Cuando se trata de la separación del front-end y el back-end, todavía existe el malentendido de que la gente solo usa el navegador como línea divisoria para separar las dos partes del código. Pero, de hecho, la intención original de hacer esto era resolver el problema del modelo de desarrollo, que es separar las responsabilidades de los desarrolladores front-end y back-end.

Esta separación es diferente para distintos tipos de productos web. Para las aplicaciones web, dado que básicamente interactúa con el servidor a través de la interfaz AJAX o WebSocket, esta separación es natural. Todo el front-end son básicamente plantillas HTML estáticas, módulos JavaScript, CSS y recursos estáticos relacionados. , funciona de manera diferente.

##Muestra la parte principal del producto

La exhibición de productos de compras en línea es muy importante. Hay muchas imágenes y otros recursos que deben cargarse, pero hay muchos. pocas operaciones. Básicamente, solo hay búsqueda de productos, agregar al carrito de compras y realizar el pago. Tradicionalmente, el flujo de trabajo de este tipo de productos es principalmente el siguiente:

Después de interactuar con un mapa de alta fidelidad, el front-end recorta el mapa, genera HTML estático y agrega efectos de visualización. a otro grupo de desarrolladores para convertirlo en una plantilla del lado del servidor, como freemarker o speed o smarty, y luego el front-end recorta el mapa. ¿Por qué hacer esto? Debido a que todos estos productos prestan atención a la optimización de la primera pantalla, que es la primera pantalla en lugar de la página de inicio, esto significa que para la primera pantalla, los pasos posteriores deben ser los menos posibles. Por ejemplo, no puede cargar la plantilla del cliente primero. , luego AJAX los datos y luego vamos a renderizar. El rendimiento de esto definitivamente no es tan bueno como generar el HTML del lado del servidor y luego cargarlo en una sola solicitud.

Definitivamente habrá algunos problemas en este proceso. Por ejemplo, ¿qué debería hacer el desarrollador B si descubre que hay un problema con parte del HTML estático original durante el proceso de configuración de la plantilla? Como todos sabemos, un desarrollador front-end que esté familiarizado con HTML y CSS y pueda escribir lógica empresarial es muy raro, por lo que en la mayoría de los casos, las habilidades de estos dos aspectos son diferentes. Si se trata de un problema de página simple, Es posible que el desarrollador pueda resolverlo él mismo, pero ¿qué pasa si no puede?

Si B no lo cambia él mismo y devuelve el código que ha creado en una plantilla del lado del servidor al personal de front-end A, A no puede comenzar porque ya es una plantilla del lado del servidor y A sí. No tengo el entorno a mano después del cambio, no sé si es correcto o no y no puedo obtener una vista previa después. Entonces, ¿qué pasa si B le cuenta a A el problema y A modifica su versión original y luego se la da a B? En este momento, B vuelve a tener problemas. Debe comparar las dos partes modificadas y fusionar sus modificaciones recientes.

Así que, hagas lo que hagas, por dentro es un desastre.

¿Qué problema intenta resolver Midway? Dado que la razón por la cual la gente del frontend no puede obtener una vista previa de las plantillas es que el backend usa plantillas del lado del servidor, ¿puedo encontrar una plantilla que funcione en ambos lados de la ecuación, es decir, que usted pueda renderizar en el lado del servidor y yo pueda obtener una vista previa del cliente? ¿Existe algún idioma que funcione tanto en el lado del servidor como en el del navegador?

Entonces, fuimos a nodejs para explorar, una biblioteca de plantillas de JavaScript universal que se puede representar en el lado del navegador y generar como HTML en el lado de nodejs. Luego, los responsables de integrar las plantillas y la lógica cambiaron originalmente. ¿Este problema no se resuelve yendo a nodejs?

Imagínese lo maravilloso que es este escenario: el front-end determina si una plantilla se representa en el lado del servidor o en el lado del cliente. Cuando aparece la primera pantalla, el HTML se genera dentro de nodejs, no cuando aparece la primera pantalla. aparece, que se muestra en el navegador mediante renderizado AJAX.

Desde una solución técnica, esto es bueno, pero la ingeniería trae algunos otros problemas, es decir, aumenta la demanda de desarrolladores de JavaScript capacitados. Para una empresa como Alibaba, hay cientos de personas en el front-end y otras empresas solo pueden mirar hacia arriba. Por supuesto, pueden hacerlo libremente, pero para nosotros en Suning, el número de personas en el front-end no es demasiado. muchos, lo cual es un problema. Si también introducimos un programa de este tipo, nos enfrentaremos al problema de que una gran cantidad de desarrolladores de Java se conviertan en desarrolladores de JavaScript. Este problema definitivamente no se resolverá en el corto plazo, lo que a su vez aumentará la presión sobre el front-end. Por lo tanto, no podemos adoptar el plan de Alibaba por el momento. Sólo podemos trabajar duro para mejorar los niveles de personal y luego ver cómo van las cosas.

Introducir nodejs en el lado del servidor tiene otras ventajas, como la integración de solicitudes. Esto también se puede resolver de otras maneras, como agregando un servidor web isomorfo de backend dedicado y existente para hacer estas cosas allí.

##Productos con una visualización y una lógica empresarial equilibradas

Para otros escenarios, existen problemas similares, como los productos de pago, donde la visualización es relativamente menos importante, pero no se puede contar. Para las aplicaciones web, nos enfrentamos a otra situación de separación del front-end y el back-end. En este caso, el front-end viene con JavaScript para HTML estático y clases de manipulación DOM, y el desarrollador de negocios es responsable de escribir el back-end, así como otra parte de la lógica de negocios en JS.

¿Cuál es el problema aquí? Este es el problema de colaboración causado por el código de estilo jQuery. Por ejemplo:

$(".okBtn").click(function() { $.ajax(url, datos) .success(function(resultado) { $("someArea").html(_ . template("tpl", result)); }); });

Debido a la escasez de personal de front-end, le resulta imposible ayudarle a escribir la lógica empresarial. De esta manera, $.ajax va dentro. Algunos empleados de la empresa tendrán que escribirlo ellos mismos. Luego, una vez que tengas los datos, tendrás que ocuparte de la parte de la interfaz.

En muchos escenarios, la interfaz de procesamiento está lejos de ser simplemente una plantilla, por lo que a los desarrolladores de negocios les resulta muy molesto. Para un problema tan pequeño, tienen que acudir repetidamente al personal de front-end para resolverlo. eso, lo cual es muy molesto. Es problemático, no tengo mucho tiempo, así que estoy muy angustiado.

Esta es también la separación entre front-end y back-end, pero la línea divisoria no está en el navegador, sino en: si se debe escribir lógica empresarial. Para esta situación, la solución es fortalecer la planificación del código JavaScript. Hay tantos marcos MV * intermedios y de front-end populares ahora. No creas que Angular es demasiado pesado, echemos un vistazo a los problemas que resuelve como Backbone.

Mucha gente dice que aunque Backbone es pequeño, no puede resolver el problema en absoluto. Hay algo de verdad en esta afirmación, pero la premisa es que debes hacer tu propio trabajo de capas de código JavaScript. Si las capas no se hacen bien, Backbone puede ayudarle a hacerlo.

El error en el código de ahora es que la responsabilidad no está clara. Una función solo puede hacer una cosa, que es joder conocimiento, pero debido a la existencia de devoluciones de llamada y otros métodos, esto inadvertidamente destruye la unicidad e integridad de la función. Intentemos analizarlo.

Para los desarrolladores back-end, ¿por qué a menudo no se atreven a escribir código front-end? ¿Es por el lenguaje JavaScript? En realidad no, cuando escribimos lógica de negocios, solo usamos un subconjunto muy pequeño de JavaScript. Para este subconjunto, no es demasiado difícil de aprender. Las partes más problemáticas son DOM, BOM, etc., para un desarrollador de back-end. Si le pide que los aprenda mientras domina la escritura de código del lado del servidor, de hecho es un poco difícil de aprender. Así que dejémosle ahorrar algo de esfuerzo.

Ahora nuestro punto de partida es dividir estos códigos para que los escriban dos personas diferentes. Una persona opera el DOM y la otra persona solo escribe lógica y nunca opera el DOM. Divida el código anterior para el mantenimiento de front-end y divida el último código para los desarrolladores comerciales.

La forma más antigua:

a.js

$(".okBtn").click(function() { b1(data);}) ; function a1(resultado) { $("someArea").html(_.template("tpl", result));}

Esta es la forma más antigua:

a. js

$(".okBtn").click(function(function() { b1(data);}); function a1(resultado) { $("someArea").html(_ .template ("tpl", resultado));}

b.js

función b1(datos) { $.ajax(url, datos) .success(a1);}

¿Todos entienden ahora?

Si hacemos esto, AB tendrá que llegar a muchos acuerdos, lo que significa que todo el proceso sigue siendo una cadena en espiral. Por ejemplo, A escribe un. Haga clic en Enlace de eventos, y luego recordó que tenía que llamar a una solicitud aquí, por lo que fue a B para escribir el método b1. Cuando B escribió b1, recordó que tenía que llamar a un método de visualización de interfaz a1, y luego fue. volver a A para escribir el método. , moviéndose de un lado a otro.

Además, un día, A querrá llamar a b1 en otro lugar, pero como la devolución de llamada de b1 está codificada. Una forma más estúpida es juzgar nuevamente en a1. Si se hace clic en algo y luego se llaman diferentes devoluciones de llamada respectivamente, este código será realmente ilegible.

hacer clic(función() { tipo = 2; b1(datos );});función a1(resultado) { if (tipo1) { $("someArea").html(_.template("tpl", resultado)); } else if (tipo2) { // ...} tipo = 0;}

b.js

función b1(datos) { $.ajax(url, datos) . Success(a1);}

Un enfoque ligeramente mejor es devolver la promesa de esta solicitud directamente en b1, para que la persona que llama pueda decidir qué hacer.

El siguiente contenido:

a.js

$(".okBtn").click(function() { b1(data).success(function ( resultado) { $("someArea").html(_.template("tpl". result) });});$(".okBtn1").click(function() { b1(datos). éxito (función(resultado) { // ...});});

b.js

función b1(datos) { return $.ajax(url,datos) }

Si desea devolver datos de manera uniforme, puede volver a encapsular fácilmente la devolución con una promesa en b1, excepto en a.js. Llamado directamente en a.js en lugar de hacerlo correctamente.

Tenga en cuenta que este código tiene algunos problemas, como una gran cantidad de funciones globales, que no son modulares y propensas a conflictos. Además, no hay lugar para almacenar en caché algunos datos ****, como en el siguiente escenario:

Hay dos bloques M y N en la interfaz, donde M carga datos durante la carga inicial. y N no es la carga inicial, pero se carga cuando se hace clic en un botón, y hay una lista en M y N. Estos datos se originan en la misma solicitud del lado del servidor.

Ahora la pregunta es, cuando N se carga, ¿cómo obtiene los datos?

Desde una perspectiva, si no hay una nueva solicitud, ¿de dónde deberían provenir los datos para N? Mirándolo desde otra perspectiva, si volvemos a solicitar y descubrimos que los datos han cambiado en comparación con los datos anteriores, ¿deberíamos sincronizarlos con M y cómo deberíamos sincronizarlos con M?

Veamos un framework como Backbone, ¿qué tipo de mecanismos proporciona? O, si no lo usamos, ¿cómo podemos encapsular mejor estas capas?

Primero, cree un modelo de datos y agréguele caché de datos:

define("model", [], function() { var Model = { data: null, queryData : function(param, fromCache) { var aplazar = q.defer(); if (fromCache || this.data) { aplazar.resolve(this.data } else { var self = this.ajax(url, param); ).success(function(resultado)) { self.data = resultado; defer.resolve(resultado } } return defer.promise }.}; forma en que almacenamos en caché los datos en el modelo, si se llama con el parámetro fromCache leeremos los datos del caché; de lo contrario, se solicitará un nuevo caché.

Para mantener la interfaz de la persona que llama consistente en ambos casos, encapsulamos la función completa en una promesa para la próxima llamada. El modelo aquí se define como un singleton, se supone que es globalmente único y se puede ajustar para que sea instanciable según sea necesario.

En este punto, la capa de vista encapsulará el DOM y la asociación de eventos:

define("vista", ["modelo"], función(Modelo) { función Vista(elemento) { this. elemento = elemento; this.element.selector(".okBtn").click(function() { var self = this; var fromCache = true; Model.queryData({}, false).entonces(function(resultado) ) { self . renderData(resultado); } }); Ver.prototipo = { renderData: función(datos) { this.element.selector("someArea").html(_.template("tpl", result )) ; };});.};});

Esta vez, los datos también se utilizan mejor en múltiples instancias de vista.

De esta manera, el front-end escribe la vista y el back-end escribe el modelo, de modo que se pueda lograr dicha división del trabajo.

Este es solo un método muy simple. Todavía existen muchas deficiencias en escenarios de aplicaciones complejos, que no se discutirán aquí. Los escenarios más complejos son similares a los de las aplicaciones web, que se analizarán más adelante en un artículo aparte.

##Resumen

Revisemos los problemas que se resolverán mediante la separación de front-end y back-end, que es la separación de responsabilidades de los desarrolladores de front-end y de negocios. Sin duda, la forma de configurar la solución debe basarse en la situación del equipo. Por ejemplo, el front-end de Alibaba es poderoso y hay mucha gente que tiene que empujarlo hacia atrás para ocupar la capa intermedia. Para una empresa como Suning, el front-end es relativamente débil, por lo que en muchos escenarios solo podemos abandonar la capa intermedia, de lo contrario, el frente de batalla será demasiado amplio y seremos pasivos en todas partes.

La misma isla Midway, en diferentes escenarios, ya sea para ocuparla o no, es un tema muy desafiante para los arquitectos front-end.

Continuaremos observando la práctica de Ali y encontraremos y crearemos oportunidades adecuadas para atacar.

Respuesta de Rank (4 votos):

Breve comentario.

El front-end ya no continúa funcionando "simplemente" en Kissy, sino que puede considerar una arquitectura que se extiende hacia atrás. Este es un progreso del front-end. Esta arquitectura de front-end redefinirá el trabajo de Alibaba. Ingenieros de front-end. Muchas empresas de Internet están un paso por delante de Alibaba.

Esta idea tiene mucho que ver con el hecho de que muchos de los primeros front-end de Alibaba no tocaban el back-end (como las plantillas). El uso de NodeJS como capa intermedia puede resolver los problemas que tenemos. enfrentamos ahora, y no se limita a resolver los problemas actuales.

Para ser específicos, que el problema pueda resolverse y resolverse bien depende de los detalles, no de la novedad, sino de la transición. Por ejemplo, cómo hacer la transición del NodeJS actual para interactuar con los datos originales, cómo hacer una transición gris, cuál es la carga de trabajo, etc.

La idea de la plataforma y la interfaz (la interfaz de datos de back-end existe en forma de Servicios) ha hecho que las ganancias de Amazon sean muy superficiales. Hoy en día, la interfaz de la plataforma de back-end es una tendencia obvia entre las grandes empresas. .

La plataforma requiere más opciones y más rápidas de desarrollo de la capa de aplicaciones, y NodeJS es una buena opción. Aunque NodeJS todavía tiene algunos problemas, desde la perspectiva de la información y nuestra propia experiencia con las aplicaciones, gradualmente se ha convertido en una buena opción para aplicaciones web back-end.

En general, esto es una tendencia.

Respuesta de Hex (1 voto):

Creo que este es el llamado modelo de desarrollo front-end grande. Este modelo es realmente bueno, pero en la práctica encontrará muchos problemas de comunicación y coordinación con los ingenieros de back-end.

Varios proyectos que he realizado han adoptado este gran modelo de desarrollo front-end. El front-end se basa en el marco Transformers + CodeIgniter para formar un front-end grande, de modo que el front-end y el back-end. -El aislamiento final se puede lograr realmente y la mantenibilidad del proyecto se puede mejorar enormemente.

Respuesta de Deng Xinxin (1 voto):

Fui a Hangzhou la semana pasada y tuve algunos intercambios técnicos con mis antiguos colegas de Alibaba y descubrí que el front-end de Alibaba está en proceso. Este año se han realizado grandes esfuerzos; el proyecto en Midway Island debería ser realizado por el equipo de UDC. Hay casos de transformación de eBay a nodejs en el extranjero. También hay casos anteriores de movilidad de Baidu Music en China;

Pero para el front-end de Ali, es de gran importancia y resuelve un gran problema en el proceso de cooperación: antes, el front-end de Ali acababa de escribir una demostración estática. y un conjunto de plantillas para el desarrollo. No sabía mucho sobre el HTML desarrollado, así que omití Escribir etiquetas y luego buscar la depuración del front-end es muy tortuoso, pero es algo que no tiene mucho contenido técnico. ; una isla en el medio. Puede resolver muy bien este molesto problema, pero no crea que el front-end será el back-end. Es solo que los navegadores solían usar ajax para solicitar la interfaz. Ahora usamos node bo y release, y puede ser. hecho con un comando, es realmente conveniente;

dip: plataforma de interfaz de datos, una plataforma pública interna basada en el esquema json que define el formato de datos de las líneas comerciales de front y back-end. Parece que también puede proporcionar una maqueta.

uitest: plataforma de integración continua front-end; estuve trabajando en esto antes, parece que acaba de lanzarse, similar a jenkis. Envíe o publique el código y ejecute un caso de prueba para usted primero. ; actualmente una biblioteca de prueba general. Relativamente pocos.

Trace: Parece que se llama así, plataforma de monitoreo. Es relativamente temprana y se utiliza para monitorear el funcionamiento de cada línea de páginas comerciales y recopilar diversos datos del usuario, como análisis y UA.

En mi opinión, def y dip juegan un papel más importante en el front-end de Alibaba, y se estima que uitest es de uso promedio. El front-end de Alibaba no se centra en la calidad del código, sino solo en algunos casos de prueba importantes. y también le ayuda a ejecutar casos de prueba. Los casos de prueba se escriben sólo para unas pocas líneas comerciales importantes que afectan directamente la transacción.

Respuesta de Xu Wenmin (0 votos):

Es realmente bueno separar el front-end y el back-end en términos de responsabilidades y los nodejs se convertirán en la habilidad básica. de los ingenieros de front-end

Respuesta de Hunter Bean (0 votos):

No confunda front-end y back-end:

No No complicar problemas simples para una empresa del tamaño de Taobao. En términos generales, algunos cambios afectarán a todo el cuerpo. Es mejor sopesar los riesgos y beneficios del cambio y no hacerlo demasiado complicado. Es mejor sopesar los riesgos y beneficios antes de tomar una decisión. Somos usuarios de tecnología y no podemos dejarnos guiar por la tecnología.

Respuesta de Luo Zhengye (2 votos):

Los expertos en front-end ya lo han dicho, déjame hablar de ello desde otro ángulo.

Digámoslo de esta manera, la razón por la que el front-end de Alibaba ha llegado más lejos que otras empresas es porque tienen muchos front-end y muchos expertos en front-end, y no necesitan escribir mucho. de la lógica empresarial. El papel de Daniel es lanzar. El nivel de los ingenieros de front-end de Alibaba ha alcanzado el nivel de los de back-end en sus propias áreas de práctica.

Pero esta llamada separación arquitectónica en realidad deja muchas de las tareas de front-end que no era necesario realizar a nosotros mismos. Aumenta los KPI de los arquitectos de front-end, lo que permite que el front-end las realice. más, y los informes semanales también se pueden escribir bien. Debido a que tanto nodejs como el front-end son js, el costo de aprendizaje no es demasiado alto, pero los requisitos para el personal técnico son más altos que antes.

Sin embargo, su equipo tiene muchos HC y mucho dinero. Entonces, si solo tengo una o dos líneas de productos de front-end, si hago esto, no podré seguir el ritmo del reclutamiento, sin mencionar que para entonces estaré agotado.

Por lo tanto, la selección y la arquitectura de la tecnología aún deben basarse en las capacidades y el reclutamiento de su propio equipo.