¿Métodos para separar front y back-end con javascript de pila completa?


31

Supongamos que tengo un front-end que es principalmente una aplicación de una sola página escrita usando angular, gruñido y bower. Y supongamos que tengo un back-end, que es principalmente una API REST que se encuentra encima de un ORM, que almacena / recupera objetos de una base de datos, usando cosas como gruñir, expresar y secuenciar.

La aplicación angular hace todas las cosas visuales que ve el usuario, pero lo hace al ser una GUI sobre los servicios proporcionados por el back-end.

Sería deseable separarlos en dos bases de código diferentes, para permitir el desarrollo independiente, el control de versiones, la integración continua, el impulso al desarrollo, etc.

Mi pregunta es, ¿qué métodos existen para hacerlo limpiamente? ¿Hay mejores prácticas recomendadas para javascript de pila completa?

La opción n. ° 1 parece ser un monolito, es decir, "no los separe". La ventaja es que la cadena de construcción es simple y todo está en un solo lugar, pero parece que hay muchas desventajas; más difícil de versionar de forma independiente, un frente roto significa una parte posterior no desplegable, y así sucesivamente.

La opción n. ° 2 parece ser un cuasi-monolito, donde la cadena de compilación del front-end resulta en escribir un montón de archivos en el back-end. El distdirectorio en el front-end se referiría a algún directorio en el back-end, por lo que esencialmente cuando el front end minimiza, uglifica, etc., termina publicando en el back-end, que ejecuta todo.

La opción n. ° 3 parece una separación total: el front-end y el back-end ejecutan sus propios servidores en diferentes puertos, y son proyectos completamente separados. El inconveniente parece ser que deben configurarse para conocer los puertos de cada uno; el back-end debe permitir CORS desde el front-end, y el front-end necesita saber dónde se espera que estén todos esos puntos finales.

La opción n. ° 4 podría ser usar algo como docker-compose para armar todo.

Estoy seguro de que hay otras opciones. ¿Cuál es la mejor práctica recomendada?

Respuestas:


18

Es una aplicación front-end, back-end, con una interfaz REST en el medio. Ya tienes una separación total.

Mi voto es por la opción # 3. Parece preocupado por la configuración, pero de eso se trata. La configuración le permite tener una separación completa sin requerir enlaces de código estrechamente acoplados. Si le preocupa CORS, coloque todo en un dominio. Si debe tener CORS, la mejor manera de administrar eso es una configuración.

Pero no hay "mejores prácticas" aquí. La mejor práctica es la que mejor satisfaga sus necesidades específicas.


2
¿Cómo pondrías todo en un dominio si son dos servidores separados? Incluso si se ejecutaran en el mismo host, tendrían que estar en puertos diferentes, lo que los haría de orígenes diferentes.
FrobberOfBits

1
Si no hay una mejor práctica, ¿hay ejemplos disponibles sobre cómo se realiza esta configuración?
FrobberOfBits

77
Puede colocar un proxy inverso (nginx) delante de su aplicación y montar la /ubicación en localhost:3000(servidor frontend) y /api/en localhost:3001(servidor api). nginx escuchará el puerto http predeterminado entonces.
nvartolomei

@nvartolomei Estoy de acuerdo con el uso de proxy inverso. ¿Hay alguna manera de compartir limpiamente información entre el backend, el front end, como la información de rutas? Además, ¿es fácil apuntar su proxy inverso a una CDN?
Andrew Allbright

6

Sí, debe separar los dos y tratar la aplicación front-end como una aplicación de terceros: eventualmente puede agregar otro cliente, una aplicación móvil, por ejemplo, y si el primer cliente se ha creado de esta manera, su vida será más fácil.

El uso de contenedores docker u otro sistema de implementación corresponde principalmente al backend, ya que el front-end de su aplicación son solo activos estáticos que deben resolverse. Puede alojar esos activos estáticamente en su servidor o en otro lugar como un CDN como cloudfront.

Evitar cors te ahorrará una pequeña configuración, pero como se menciona en la respuesta anterior, ese es el punto. El uso de cors (y autenticación de token) también preparará mejor su backend para otros clientes.

Editar: en cuanto a las mejores prácticas de full stack js, solo diría esto, sea coherente. Si usa promesas (y debería hacerlo), hágalo en ambos lados. Mantenga el mismo estilo y formato js, ​​use las mismas bibliotecas de prueba (cuando sea posible), etc.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.