En la programación, ¿implementan el front-end o el back-end primero?

Cualquier cosa con la que te sientas más cómodo. Realmente no importa, pero en aras de ser sincero, generalmente comenzaría con modelos de datos. Me ayuda a “moldear” mis pensamientos.

Siendo realistas, lo que realmente quiere preocuparse son sus puntos finales de API. Son como contratos del mundo del software. Desea mantenerlos intuitivamente simples, lo suficientemente robustos como para que no sea probable que los cambios cambien en el futuro cercano, así como … No estoy seguro de cómo describir esto, lo suficientemente “simple” que cuando desarrolla su frente / parte posterior Al final, no necesita escribir ningún truco feo para que el código funcione.

Por supuesto, tampoco puede ignorar las preocupaciones arquitectónicas generales de su aplicación, pero tener una capa API bien pensada puede hacer las cosas mucho más fáciles a largo plazo.

Espero que esto ayude. Buena suerte 🙂

  1. Primer enfoque frontal
  • Preferido cuando no va a recibir los requisitos de cambio de UI.
  • Generalmente, los wireframes se preparan con el flujo y la navegación adecuados y, en consecuencia, se diseñan modelos. A veces simplemente codifica los datos cuando su backend no está listo. Una vez que esté preparado con el programa de fondo, estos modelos se modifican para obtener los datos de los puntos finales API.

2. Primer enfoque de back-end

  • Se prefiere cuando está tranquilo y seguro acerca de los datos principales que va a proporcionar a Front End. La mayoría de los desarrolladores toman este porque cualquiera que sean los requisitos de la interfaz de usuario son datos subyacentes, la mayoría de las veces no se modifica.

3. Enfoque de la mano

  • Ambos se desarrollan juntos y esto resulta útil la mayoría de las veces cuando está trabajando en una startup donde necesita mostrar algo presentable para cumplir con “esos” plazos. Esto permite la flexibilidad con el cambio de requisitos.

¡Pero uno es libre de elegir lo que considere adecuado con …!

En la startup en la que estoy trabajando en este momento, estamos haciendo ambos al mismo tiempo.

Estamos creando aplicaciones para Android, Windows UWP, Mac e iOS y todo lo relacionado con el servidor al mismo tiempo.

Si necesita hacer las cosas rápidamente, esta puede ser una opción decente, pero significa que si decide cambiar algo, debe regresar y cambiar el cliente y el servidor. Sin embargo, facilita la iteración y las pruebas, porque nuestras aplicaciones están hablando con un servidor real, no con trozos y pruebas, y tiene una idea de cómo funcionarán las cosas en el mundo real.

Lo que sucede la mayoría de las veces es que espero para diseñar una página web hasta que todo funcione.

La razón de esto es que el backend de un sitio web suele ser el más complicado y, a veces, requiere que cambie lo que hay en una página web para que funcione. Así que paso mi tiempo protagonizando un montón de código y luego mirando la página web para ver un montón de HTML sin personalización, por lo que se ve bastante mal.

aparte de eso, The Backend es el primero.

Es un poco difícil probar el front-end sin tener un back-end.

Por lo menos, las API deben definirse, o incluso es difícil iniciar el front-end. Después de eso, uno necesita al menos stubs para cada API para permitir cualquier prueba de front-end.

Dicho esto, hay excepciones, por ejemplo, cuando su aplicación es esencialmente una combinación de servicios de fondo existentes (por ejemplo, la gran cantidad de aplicaciones que trazan diferentes conjuntos de datos en Google Maps). Entonces es casi todo el trabajo de front-end.

En mi caso, escribí el back-end para apoyar el front-end porque el front-end constantemente presentaba nuevas ideas para implementar, así que no tenía toda la historia. Finalmente trabajas con lo que tienes.