Al hacer una aplicación, ¿debe hacer que el front-end sea el primero o el back-end?

Depende del contexto, el software que desea construir, etc.

De hecho, hay dos enfoques para diseñar un software con una interfaz de usuario: “de arriba hacia abajo” y “de abajo hacia arriba”.

De arriba hacia abajo: construye la interfaz de usuario, luego agrega los servicios que faltan en las capas inferiores, hasta llegar a la parte inferior (por ejemplo, la base de datos)

De abajo hacia arriba: diseña la base de datos, crea los servicios, los integra y agrega el front-end.

Ambos enfoques tienen sus ventajas y desventajas, y a menudo me refiero a esta página: Estrategias de diseño: de arriba hacia abajo frente a abajo hacia arriba.

Noté un riesgo con el enfoque de arriba hacia abajo. Algunas personas dicen que la interfaz de usuario de un software es como la parte visible del iceberg. Como resultado, muestra la interfaz de usuario a sus clientes potenciales y pensarán que el software está terminado.

Depende de lo que esté haciendo y también de los marcos que esté usando. En general, se desarrollan en conjunto, pero digamos, por ejemplo, que estaba creando una plataforma de redes sociales. Primero querría construir el backend con todas las rutas para manejar todo el intercambio de datos / inicio de sesión / etc. Si estaba creando un sitio web de cartera, no es necesario un backend ni es relevante. Todo depende de lo que estés haciendo.

En cuanto a los marcos, si está usando algo como Angular, podría tener más sentido construir una interfaz con maquetas sobre cómo deberían funcionar las rutas para que sepa qué rutas de back-end necesita antes de escribir el back-end.

Use su mejor criterio y descubra lo que necesita primero. Dependen unos de otros y generalmente deben desarrollarse juntos.

Ambos.

Lo mejor es dividir su aplicación en pequeños segmentos de historia, moda ágil.

En lugar de crear una aplicación bancaria completa, cree suficiente IU para crear una cuenta, y suficiente back-end para almacenar esa cuenta creada.

Hay varias ventajas para esto

  • Pruebas tus decisiones de arquitectura
  • Muestras progreso
  • Puede recibir comentarios de los usuarios para dirigir el siguiente segmento
  • No te abrumas
  • No obtendrá fallas catastróficas de integración en el futuro, donde encontrará que no se hablarán entre sí

Entonces haces la siguiente rebanada

Primero debe aprender el flujo del software que está creando. Cuando las cosas van de frontend a backend y viceversa.

Estas cosas deberían ir bien. Puede comenzar a construir el backend primero, ya que hay algunas herramientas que lo ayudarán a enviar solicitudes al backend sin tener nada en la interfaz, como Postman, por ejemplo.

La otra cosa es que a veces el cliente quiere una nueva característica en la aplicación que implique una solicitud al backend y que ya tiene una interfaz avanzada, por lo que debe trabajar en la interfaz y el servidor al mismo tiempo.

Puede trabajar en su backend primero si lo desea, pero cuando construya la interfaz, se dará cuenta de que necesita hacer algunos cambios nuevos, como validaciones y cosas por el estilo.

No hay una forma segura de iniciar el software desde un lugar u otro. Puede tener un backend separado de la interfaz o si lo desea, podría estar en el mismo proyecto. Si desea escalabilidad, entonces trabaja el backend separado del front-end para que pueda tener tantas aplicaciones como necesite haciendo solicitudes al mismo backend.

Por supuesto, el backend, primero! Un backend de diseño sólido es un trabajo que ya está a medias. Diseñar el backend primero y ser parte de ese proceso de diseño le dará un conocimiento más profundo sobre la aplicación y lo hará más productivo en la distribución de una aplicación poderosa.