En la creación de una aplicación web, desarrollo front-end o back-end, ¿qué es lo primero?

Ninguno o ambos, dependiendo de cómo lo mires.

Lo primero que debe hacer es lograr que algo (cualquier cosa) funcione de principio a fin. No me refiero a MVP (producto mínimo viable), me refiero a “hola mundo”.

Configure todo y pueda atender solicitudes triviales (por ejemplo, hable con la base de datos para obtener / configurar su nombre, haga que su javascript cambie su color cada 10 segundos).

Una vez que tenga la pila completa en funcionamiento y pueda ejecutar las solicitudes, comience a agregar funciones. Nunca intentes construir un gran trozo a cada lado de una sola vez: desglosarlo en las unidades más pequeñas posibles y construirlo.

Desea enfocar su rutina de desarrollo en la iteración rápida. Acostúmbrese a echar pequeñas cosas rápidamente y configurar su cadena de herramientas / flujo de trabajo / etc. para que coincida.

Acepta que todo lo que escribas desde el principio se irá por la ventana, pase lo que pase, así que no te preocupes demasiado por la complejidad o la perfección. No hay sustituto para lo que funciona.

A partir de ahí, serás el proceso de modularización. Se tienen en cuenta diferentes aspectos de la interfaz de usuario, a alguien se le ocurre un tema unificador, y eso se repite. El backend se piratea en microservicios pieza por pieza.

Pero pensar en términos de “backend o frontend primero” es en última instancia contraproducente.

Normalmente construyo algunas de las cosas de back-end primero. La fontanería o cimentación, esencialmente. Este sería su enrutamiento, configuración global, seguridad y autenticación de usuario, funciones auxiliares y funciones principales, por ejemplo, un controlador de solicitudes Ajax.

Mi razonamiento es que hay capacidades mínimas que necesito para comenzar a construir el front end y poder verlo e interactuar con él de una manera significativa.

A veces me olvido de usar este enfoque, pero creo que el enfoque más efectivo para construir el front-end es dibujarlo o enmarcarlo antes de comenzar a escribir HTML, CSS o JavaScript. Por supuesto, una vez que comience, normalmente encontraré que el back-end evoluciona con el tiempo.

Esa es una buena pregunta. Y algo con lo que lucho a veces. (ejemplo: configurar un sistema de comentarios de una determinada manera, luego tener que volver más tarde y modificarlo porque no coincide con el flujo de cómo id como funciona la aplicación).

No obstante, en mi experiencia, siempre he hecho la parte posterior y frontal en paralelo.

Antes de bucear demasiado profundo en el extremo frontal o posterior, creo que es importante crear un diagrama o mapa mental del flujo del usuario. ¿Cómo se manejarán los registros? La navegación? ¿Será diferente para los usuarios que hayan iniciado sesión? ¿O usuarios que pagan? Etcétera.

Personalmente, si siempre planifiqué la organización a fondo en lugar de saltar directamente, tendría horas de tiempo ahorrado. Tal vez incluso días …

De hecho, prefiero hacer ambas cosas al mismo tiempo.

Déjame explicarte … Digamos que estoy creando una aplicación, lo primero que hago es diseñar el front-end. Se trata principalmente de cuadrículas, botones, colores, etc. Más adelante, si me da la gana, generalmente inicio un nuevo proyecto de API web .NET o empiezo a crear los archivos PHP esenciales. Si estoy desarrollando Facebook, los archivos de backend iniciales serían reunir todas las publicaciones. En primer lugar, diseño las cuadrículas y los bloques para las publicaciones, y luego conecto una solicitud HTTP al back-end.

Ahora he desarrollado ambos simultáneamente :). Luego puede repetirlo para cada función de su aplicación.

Creo firmemente en el desarrollo backend-first. Si aún no sabe qué información debe proporcionar y administrar su aplicación, entonces no ha diseñado correctamente su solución, lo cual es un problema grave. Si lo hace, entonces el backend es fácil y, más concretamente, le proporciona las herramientas diseñadas adecuadamente que necesitará para alimentar su interfaz.

Para usar un ejemplo físico, desarrollar frontend primero es muy parecido a construir paneles de pared con estilo, un bonito piso de madera y un techo bellamente texturizado … luego romper agujeros en el piso para verter una base, romper paneles de pared abiertos para instalar montantes, cableado y fontanería, y romper agujeros en el techo para agregar vigas y conductos de aire acondicionado. No solo está perdiendo mucho tiempo, el resultado final será un desastre terrible. Construye lo básico antes de decorar.

Realmente depende de cómo estoy construyendo la aplicación. Si estoy usando algo como plantillas del lado del servidor, primero configuraré el backend para que las plantillas se puedan representar. En el caso de que solo esté usando HTML simple, generalmente configuraré el frontend primero. La razón por la que hago eso es porque diseñar la aplicación es la parte más emocionante, en mi opinión. Realmente no hay una respuesta correcta o incorrecta.

Cuando estaba aprendiendo desarrollo, aprendí cómo crear la interfaz primero. Los nuevos desarrolladores casi siempre aprenden eso primero. Después de que me sentí cómodo con la interfaz, comencé a aprender sobre el backend. Con cada aplicación posterior que desarrolle, mejoraría cada vez más. Durante ese tiempo, siempre crearía el frontend primero ya que me sentía más cómodo con él. Ahora que tengo confianza en el frente y el backend, solo hago lo que tiene más sentido.

Recomendaría comenzar con el front-end por una y solo una razón: el front-end es lo que usan sus clientes. El front-end es la puerta de entrada a su producto y desea crear una experiencia mágica. * A la mayoría de sus clientes no les importa el back-end.

Así que tenga en cuenta al cliente, comience con el front-end. Aumentará sus posibilidades de éxito.

Si está creando una aplicación web moderna, donde las API RESTful de back-end serán consumidas por el front-end, entonces ambos podemos trabajar en paralelo. Antes de comenzar el desarrollo solo necesita tener un esquema de API que se desarrollarán y consumirán. El esquema se referirá a la firma de la API y al formato de las respuestas devueltas por las API.

De acuerdo, imagine que primero tenía que desarrollar el front-end, ¿qué tendría que hacer con todas las características que faltan en el backend? Burlarse de ellos, por supuesto!

Si la aplicación tiene mucha funcionalidad, podríamos estar tropezando con muchos componentes y desperdiciando demasiado desarrollo en componentes simulados que en los reales.

En cambio, es mucho más fácil desarrollar el backend primero, al menos los componentes centrales de todos modos, luego construir el núcleo del front-end.

Una vez que la funcionalidad principal está fuera del camino, agregar nuevos componentes debería ser relativamente sencillo y trabajar en ambos extremos simultáneamente debería ser lo suficientemente simple.

El desarrollo del front-end lo hace pensar en qué datos necesita recopilar y qué datos debe proporcionar a sus usuarios.

Desde aquí puede pensar dónde deben terminar los datos, ya sea en una base de datos, en un archivo, enviados a un procesador de pagos, etc. Puede comenzar a diseñar su base de datos y crear tablas o estructuras de directorios, y pensar en datos adicionales que sería útil para almacenar (incluso si el usuario final no lo ve).

Finalmente, puede compilar la aplicación para mover datos entre la interfaz de usuario y el almacenamiento.

Ese es mi enfoque. Me parece que es eficiente.

Ninguno. El diseño / documentación de la API es lo primero. La API es el “contrato” en el que el front-end (FE) y el back-end (BE) tienen que estar de acuerdo. El FE debe cumplir con este contrato cuando realiza llamadas al BE, y el BE debe cumplir con el contrato cuando acepta llamadas del FE.

Una vez que se diseña la API, generalmente escribo y pruebo el BE primero. Luego, cuando comience a escribir el FE, tendrá algo a lo que debe llamar. De lo contrario, tendrá que escribir un montón de apéndices (código que simula la llamada y la respuesta del BE) en el FE que luego quedarán obsoletos una vez que conecte el FE al BE real. ¿Por qué perder el tiempo para escribir talones que pronto tirarás?

Si se siente cómodo con el uso de datos de muestra en lugar de datos reales en el front-end, puede hacer ambas cosas simultáneamente. Pero si no puede, le sugiero que comience desde el backend y una vez que esté seguro de que al menos puede comenzar a construir la interfaz, puede comenzar su trabajo en ambos.

En general, una aplicación web requiere una base y el backend es esa base. Además, es mi opinión personal que cualquier modificación en el front end es más fácil en comparación con el backend. Por lo tanto, si comienza desde el backend, conocerá sus requisitos y escenarios exactos, lo que le ahorrará tiempo y esfuerzos en el futuro para realizar modificaciones.

¡Es como un problema de pollo y huevo!
Ambos van de la mano ya que cada uno cumple un propósito específico en su aplicación.
Intenta leer sobre el patrón de diseño MVC. Le ayudará a conceptualizar mejor y crear un enfoque más estructurado. Diseñar bien ayuda a reducir el 60% de los dolores de cabeza.

Esto es más una preferencia personal.

Mi preferencia es hacer ambas cosas al mismo tiempo. Déjame explicarte mi proceso …

Normalmente comenzaré diseñando el sitio primero, para saber dónde estará cada sección en la pantalla una vez que esté construida. Una vez que esté diseñado, elegiré un respaldo preconstruido (WordPress, Concrete5, etc.) según las necesidades del sitio, o construiré el mío. De cualquier manera, a medida que construyo el frontend, modificaré / compilaré los componentes del backend para que funcionen con el frontend.

Como nunca puede anticipar cómo va a reaccionar el sitio, a menos que esté usando una plantilla. Es difícil construir las dos partes en conjunto.

Sugiero construir front-end primero por la misma razón que codifica una función después de saber lo que debe hacer. El front-end informará sus decisiones sobre qué datos se necesitan realmente para construir la interfaz final, y le permitirá mantener la inclinación del back-end.

Front-end primero. Le ayudará a tener una visión general sobre la función que necesita implementar. Puede simular los datos primero, solo para asegurarse de que la función cumpla con el requisito.

Una vez que se decide el contenido estructural del sitio web. El desarrollo del back-end se inicia ya que el front-end depende de los diseños del sitio web, lo que puede demorar un tiempo en aprobarse y la otra razón es que el front-end depende del back-end.

Tipo de ambos por lo general … aunque si tiene que ser uno, generalmente el back-end ya que necesita poder usar la funcionalidad CRUD para extraer datos para que los use el front-end

Cuando diseño, generalmente comienzo con un algoritmo de “¿qué debe hacer este módulo?”, Y luego, escribo el código de acuerdo con el orden que di yendo y viniendo de la estructura 🙂

Por ejemplo, en un programa, tuve que preparar una lista de “sus contactos personales” que, si seleccionó uno, podría haber enviado un correo electrónico si ya se había entregado, o colocar uno nuevo si lo deseaba.
Primero creé la lista (frontal), luego preparé la llamada ajax (posterior), luego hice el cuadro de entrada de “correo electrónico” con alguna validación html (frontal), y luego la llamada php para recuperar el correo (posterior), finalmente el botón (frente) y el resto de validación de php (atrás).

Encuentro este enfoque realmente agradable, ya que no puede perder la noción de su trabajo y le da la oportunidad de probar si todo funciona en cada paso ^^