¿No entiendes la separación entre front-end y back-end? eso es suficiente
Antes de que se separaran el front-end y el back-end, nuestro modelo de colaboración de desarrollo era generalmente el siguiente:
El front-end escribe páginas HTML estáticas y las entrega al back-end. finalizar el desarrollo. Las páginas estáticas se pueden desarrollar localmente sin considerar la lógica empresarial y solo es necesario implementar View.
El backend utiliza un motor de plantillas para configurar la plantilla e incorpora algunas variables de plantilla y algunas operaciones lógicas proporcionadas por el backend.
Luego integre y conecte el front-end y el back-end. Si hay problemas, se reelaborará el front-end y el back-end.
Luego integre hasta que la integración sea exitosa.
Problemas con este modelo
Durante la depuración del front-end, se debe instalar un conjunto completo de herramientas de desarrollo del back-end para iniciar completamente el programa del back-end. Cuando encuentra un problema, necesita un desarrollo backend para ayudar a depurarlo. Descubrimos que el front-end y el back-end están muy acoplados y que el personal de back-end debe conocer algunos lenguajes de front-end como HTML y JS. También hay una gran cantidad de código de fondo incrustado en la página de inicio. Una vez que el backend se desarrolla en un idioma diferente, simplemente se puede rehacer.
Esto aumenta los costos de comunicación, los costos de depuración, etc., y el progreso del desarrollo front-end y back-end interactúan entre sí, lo que reduce en gran medida la eficiencia del desarrollo.
La separación de front-end y back-end no es solo un modelo de desarrollo, sino también un modelo arquitectónico para aplicaciones web. En la fase de desarrollo, los ingenieros de front-end y back-end acuerdan una interfaz de interacción de datos para lograr el desarrollo y las pruebas en paralelo; en la fase de ejecución, el modo de separación de front-end y back-end debe comenzar con la implementación de la aplicación web. es decir, el front-end y el back-end utilizan HTTP u otros protocolos para realizar interacciones de solicitud.
1. El cliente y el servidor interactúan utilizando la API RESTFul
2. Separación de las bibliotecas de códigos front-end y back-end
En el modelo de arquitectura tradicional, el código de front-end y back-end se almacena en la misma base de código, incluso en el mismo directorio del proyecto. La página también está intercalada con código de fondo. Tanto los ingenieros de front-end como los de back-end deben importar todo el proyecto a la herramienta de desarrollo durante el desarrollo.
Las bases del código front-end y back-end están separadas. El código front-end se puede burlar (simplificando el entorno de prueba mediante la construcción de objetos de prueba virtuales) y el pseudo-backend puede soportar el desarrollo y las pruebas independientes. del front-end. Además de la implementación funcional, el código backend también tiene casos de prueba detallados para garantizar la usabilidad de la API y reducir los riesgos de integración.
3. Desarrollo paralelo
Durante el proceso de desarrollo, el front-end y el back-end controlan y llegan a un acuerdo sobre la forma de interacción de la interfaz de datos y el formato de los datos. Luego, realice el desarrollo paralelo del front-end y el back-end. El ingeniero de front-end puede realizar pruebas de simulación de forma independiente una vez finalizado el desarrollo, mientras que el back-end puede utilizar software de prueba de interfaz como Postman para realizar la autoevaluación de la interfaz. Pruebe, y luego el front-end y el back-end pueden ajustar y verificar conjuntamente las funciones y formatos, y finalmente realizar pruebas automatizadas.
El modelo de desarrollo después de la separación es así
Construir un equipo eficiente y crear productos de alta calidad
Separando el front-end y el back-end de el equipo de desarrollo, los ingenieros de front-end y back-end solo necesitan centrarse en el trabajo de desarrollo de front-end o back-end, y los ingenieros de front-end y back-end pueden lograr un desarrollo independiente. De esta manera, pueden crear un equipo de desarrollo ágil y completo.
Mejorar la eficiencia del desarrollo
Una vez que el front-end y el back-end están separados, el código del front-end y del back-end se puede desacoplar siempre que el front-end y el back-end. El back-end tiene las interfaces requeridas por la aplicación y las interfaces. Una vez que se acuerdan los parámetros, el desarrollo paralelo puede comenzar sin esperar a que la otra parte termine el trabajo de desarrollo. Al mismo tiempo, incluso si los requisitos cambian, siempre que la interfaz y el formato de datos permanezcan sin cambios, los desarrolladores de back-end no necesitan modificar el código, solo necesitan modificar el front-end. De esta forma, se mejorará la eficiencia del desarrollo de toda la aplicación.
Hacer frente perfectamente a las necesidades de front-end complejas y cambiantes
Si el equipo de desarrollo puede completar la transformación de separar el front-end y el back-end, cree un buen front-end y el equipo de back-end, y separar el desarrollo. Al permitir que los desarrolladores se concentren en la especialización, las capacidades de desarrollo definitivamente mejorarán y podrán hacer frente a diversas necesidades de front-end complejas y cambiantes.
Mejorar la capacidad de mantenimiento del código
Después de separar el front-end y el back-end, el código de la aplicación ya no se mezcla con el front-end y el back-end, y las dependencias de llamadas solo aparecen en tiempo de ejecución. El código de la aplicación será limpio y claro, y la lectura y el mantenimiento del código serán más fáciles que antes.
Después de utilizar la arquitectura de separación de front-end y back-end, además de los cambios en el modelo de desarrollo, ¿qué otros problemas encontraremos durante el proceso de desarrollo? Sigamos adelante.
Echemos un vistazo a cómo realizamos la autenticación de usuario en el desarrollo tradicional.
Después de que el front-end inicia sesión, el back-end genera un jsessionid basado en la información del usuario y combina este jsessionid con el ID de usuario correspondiente se guarda en la sesión, y luego el jsessionid se pasa al usuario y se almacena en la cookie del navegador. Después de eso, el navegador solicita eliminar la cookie y el backend consulta al usuario en función de. el valor de la cookie para verificar si ha caducado.
HTTP tiene una característica: sin estado, es decir, antes y después de dos transacciones HTTP, no conocen la información de cada uno. Para mantener la información de la sesión o la información del usuario, generalmente se utilizan cookies y tecnologías de sesión para almacenar en caché la información.
- Las cookies se almacenan en el lado del cliente
- Las sesiones se almacenan en el lado del servidor
Pero hay muchos problemas con esto. Si nuestra página tuviera una vulnerabilidad XSS, dado que JavaScript puede leer cookies, la vulnerabilidad XSS podría provocar la fuga del token de usuario, que es el identificador de backend del usuario. Como identificador de backend de un usuario, la filtración de cookies significa que la información del usuario ya no está segura. Aunque podemos evitar la inyección XSS escapando del contenido de salida, usando CDN, etc., nadie puede garantizar que este problema no ocurra en proyectos grandes.
Al configurar cookies, puede configurar nv.tao.com, nz.tao.com y login.tao.com. Entonces, si desea iniciar sesión en login.tao.com y aún así obtener sesiones en otros subdominios, esto requiere que sincronicemos las sesiones en varios servidores. El enfoque JWT no tiene este problema porque el estado del usuario ya se transmite al cliente.
Cuando el cliente y el servidor se implementan en diferentes servidores, encontrarán el problema del acceso entre dominios. Este también es un tipo de escenario de solicitud restringido por la política del mismo origen del navegador.
Existen muchas soluciones entre dominios. La siguiente utiliza el proxy inverso de Nginx.
Proxy inverso
En realidad, existen muchos escenarios para el acceso al proxy en aplicaciones prácticas. En aplicaciones entre dominios, el principio práctico es escuchar el mismo puerto y el mismo nombre de dominio a través de un servidor proxy inverso y asignar diferentes rutas a diferentes direcciones. Tomando diferentes direcciones como ejemplo, en el servidor nginx, se monitorea el mismo nombre de dominio y puerto, se reenvían diferentes rutas al cliente y al servidor, y se restringen diferentes puertos y nombres de dominio mediante proxy inverso para resolver problemas entre dominios: