¿Cómo funcionan juntas las tecnologías front-end y back-end?

Creo que para responder a esta pregunta debemos comenzar con la abstracción a la que a menudo nos referimos como un patrón de diseño, y en este caso particular, el patrón de diseño “MVC”. Esto significa Modelo, Vista y Controlador, y en muchos contextos el front-end es la “Vista” (lo que ve el usuario), el back-end es el “Controlador” (lo que hace el trabajo), y la base de datos o otro almacén de datos permanente es el “Modelo” (que almacena la información para más adelante). Me gusta construir en el medio, lo que significa que primero considero lo que mi aplicación necesita HACER (como iniciar sesión en los usuarios o actualizar la información de la cuenta, o ejecutar consultas, etc.), y luego construir la lógica de negocios que utilizará para lograr esto Al hacer esto, me ayuda a definir lo que necesito almacenar (el modelo) y cómo interactuará el front-end con el back-end. Ahora, entrando en gran detalle sobre cómo se integran el front-end y el back-end.

La Vista toma muchas formas, pero en el fondo, en la web, es HTML, JavaScript y CSS. Una vista determinada (como su página de inicio o página de cuentas), o una vista parcial (tal vez su encabezado o pie de página) puede integrarse a su marco (como con las plantillas ERB en Ruby on Rails, o las plantillas Django en Django), o puede estar completamente separado (y potencialmente escrito con un marco de JavaScript front-end, como Angular, Backbone o Ember).

Esto significa que en el primer ejemplo, donde una vista se integra con el marco, a medida que se realiza una solicitud en el back-end (volveré a esto más adelante), lo que se devuelve es HTML que ha sido prestado previamente por el motor de fondo, que puede o no usar valores del controlador, e incluso puede hacer lógica usando el lenguaje de plantillas (como la plantilla ERB para Ruby on Rails o la plantilla Django en Django, como se indicó anteriormente). En el último ejemplo, todo es HTML, CSS y JavaScript (potencialmente con un marco de JavaScript), y esto cambia la forma en que el back-end devuelve datos al front-end.

Ahora, para la parte importante: ¿cómo se comunica realmente el front-end con el back-end? El front-end siempre hace una llamada , lo que significa una solicitud GET o POST en general. Una llamada puede realizarse de forma activa, haciendo clic en un enlace, en respuesta a algún evento (en JavaScript), o pasivamente (en un temporizador, también en JavaScript).

Una solicitud GET es aquella que tiene todos los valores que pasará al back-end en la propia URL (como mywebsite.com/someservice?somekey=somevalue&anotherkey=anothervalue ). En este ejemplo, cuando se realiza la llamada, realiza una solicitud de obtención al punto final “someservice” de su back-end y ha pasado los parámetros “somekey” y “anotherkey” con los valores “somevalue” y “anothervalue”.

Una solicitud POST es aquella que tiene todos los valores que pasará al back-end codificado en el cuerpo de la solicitud. En este caso, invocaría mywebsite.com/someservice , pero los valores se codificarían en el cuerpo de la solicitud. Esto sucede cada vez que completa un formulario , en cuyo caso el cuerpo de la solicitud es contenido codificado en formularios de varias partes. Esto también se puede hacer de forma activa (p. Ej., Un usuario envía un formulario), pasivamente (p. Ej., El formulario se envía en respuesta a todos los campos que se están completando) o en un temporizador (p. Ej., El front-end comprueba el back-end para algún valor en el formulario y lo valida usando el back-end cada 5 segundos).

Y esta es la esencia de la respuesta: se realiza una llamada desde el front-end hasta el back-end a través de la interacción del usuario con la página, escuchando un evento en JavaScript o usando JavaScript como un evento cronometrado . En los tres casos tenemos una opción: ¿la solicitud será síncrona o asíncrona? Sincrónico generalmente significa que el usuario realiza una solicitud y espera la respuesta. Asíncrono generalmente significa que la solicitud se realiza en segundo plano y la página (o elementos de la página) se actualizan cuando se recibe la respuesta de la solicitud. Todas las solicitudes asincrónicas se realizan a través de solicitudes XML HTTP (XHR), que puede hacer usando JavaScript simple o cualquier marco de JavaScript (incluso jQuery lo hace muy fácil).

La siguiente gran pregunta es, ¿cómo sabe el back-end, una vez que recibe una llamada del front-end, qué hacer con esta información? Lo que sucede es esto: un back-end recibe una llamada desde el front-end (como se indicó anteriormente, usaremos la solicitud GET como ejemplo), y desarma la solicitud, clasificando lo siguiente:

  • Es una solicitud GET
  • El dominio es mywebsite.com
  • El puerto es 80, para http, o 443, para https (por defecto)
  • El punto final es “someservice”

Luego toma esa información para enrutar la solicitud adecuadamente, pasando también el cuerpo de la solicitud. ¿Qué quiero decir con ruta? Supongamos que el back-end está configurado de una manera típica, con un servidor web (como Apache o NginX) y un servidor de aplicaciones (como Passenger o uWSGI, que montaría y proporcionaría la puerta de entrada a una aplicación Ruby on Rails o Django respectivamente). El servidor web toma esta información y, suponiendo que conoce el host y el puerto, y el recurso está permitido, pasará la información a la aplicación a través de la puerta de enlace.

Cuando la aplicación recibe la llamada, también necesita enrutar la solicitud de manera apropiada, que es donde “rutas.rb” y “http://urls.py” entran en su lugar (para Ruby on Rails y Django, respectivamente). Estos archivos dicen: si una solicitud coincide con un patrón dado (punto final, método de solicitud y, potencialmente, argumentos), entonces el enrutador debe enrutar la solicitud a un controlador y acción dados (a menudo un método dentro de un controlador dado).

Cuando el controlador recibe la solicitud, finalmente, se completa con el cuerpo de la solicitud, por lo que todas sus claves y valores pasados ​​están presentes. La acción del controlador (su método en su controlador) realiza la “lógica de negocios”, potencialmente comunicándose con una base de datos (para almacenar o leer información), o haciendo algún cálculo, etc. Lo que es importante acerca de las diferentes formas de hacer una solicitud (sincrónicamente) o asincrónicamente) se divide en dos partes:

  1. ¿Qué devuelve el back-end? XML, JSON o HTML normalmente, y un solo método puede devolver cualquiera de los tres dependiendo de cómo se realizó la solicitud. Esto es lo que “responde_to” hace en Ruby on Rails, cuando se trata de una solicitud asincrónica. Renderizar y redirigir son las declaraciones que utilizamos en Ruby on Rails cuando deseamos representar una vista o redirigir a otra acción. Esto también es algo que típicamente hemos decidido a través de la arquitectura, al decidir si nuestro front-end está integrado o no como plantilla en nuestro back-end, o no. Cuando un front-end se integra como una plantilla, es posible que regresemos una vista (renderizando una vista), en cuyo caso pasamos valores a esa vista, el motor de back-end lo procesa todo como HTML, y luego se devuelve al consumidor Cuando recibimos una solicitud asincrónica, nuestro controlador debe devolver XML, JSON o HTML, dependiendo de cómo el front-end recibirá e interpretará los resultados. Un buen ejemplo de esto sería hacer una solicitud de larga duración (como una consulta de base de datos grande): el consumidor no quiere esperar para recibir una solicitud, es probable que su navegador agote el tiempo de espera antes de que se devuelva la respuesta. Como resultado, la solicitud se haría de forma asincrónica, y el usuario podría permanecer en la página y esperar una actualización, en la que el back-end devuelve un bloque de HTML, o un objeto JSON que representa los resultados de la consulta, o un temporizador podría configurarse en el front-end para escuchar dicho evento, probando el back-end periódicamente.
  2. Esto nos lleva a la segunda parte para hacer una solicitud: ¿qué hace el front-end con los datos devueltos? Al realizar una solicitud sincrónica, muestra esos datos (necesariamente), lo que significa que normalmente muestra una página completa, como cuando inicia sesión en un servicio y se “reenvía” a la página de su cuenta. Al realizar una solicitud asincrónica, el front-end tiene que decidir qué hacer con los resultados. Puede tomar esos resultados y mostrarlos en la página en un lugar particular (como los resultados de la consulta anterior); puede hacer cualquier cosa como resultado de o usando la respuesta del back-end.

Agreguemos un ejemplo rápido, paso a paso, para el escenario donde el usuario visita su página de inicio:

  1. El usuario escribe en su sitio web en la barra de URL de su navegador y presiona Intro, haciendo una solicitud GET a mywebsite.com
  2. El back-end recibe esta solicitud y, conociendo el dominio, el puerto, el método y el punto final (“/”), la pasa a la aplicación
  3. La aplicación recibe esta solicitud y, conociendo el punto final y el método, la pasa a la acción correcta del controlador (diremos Controlador de aplicación y método de inicio)
  4. El método de inicio del controlador de la aplicación simplemente representa el HTML asociado a la página de inicio como una vista, pasando al HTML representado por el consumidor
  5. El navegador interpreta el HTML y el usuario ve la página de inicio

Hagamos un segundo escenario, uno en el que hacemos una consulta usando un formulario y luego los resultados de esa consulta deben mostrarse en un cuadro de texto en la página algún tiempo después:

  1. El usuario ingresa información en un formulario relacionado con su consulta (tal vez rangos de fechas o ID, etc.) y presiona el botón “enviar”
  2. JavaScript (que ha escrito) captura el evento (evita que ocurra el valor predeterminado), envuelve los parámetros de solicitud y realiza una solicitud POST de forma asíncrona a su punto final (diremos mywebsite.com/query )
  3. El back-end recibe la solicitud y, conociendo el dominio, el puerto, el método y el punto final (“/ query”), la pasa a la aplicación
  4. La aplicación recibe esta solicitud y, conociendo el punto final y el método, la pasa a la acción correcta del controlador (diremos Controlador de aplicación y método de consulta)
  5. El método de consulta del controlador de la aplicación necesita hacer algo de lógica empresarial para iniciar la consulta y proporciona una ID de consulta, que luego vuelve al front-end como JSON (por ejemplo, {'query_id': 1234} )
  6. El front-end recibe esta respuesta a través del oyente asíncrono que escribió y configura un temporizador para escuchar la finalización de la consulta
  7. El front-end usa JavaScript (que usted ha escrito) para hacer una solicitud POST al back-end cada 5 segundos, (diremos, mywebsite.com/queryresults ), pasando el “query_id” que recibimos en el anterior paso como el cuerpo de la solicitud
  8. Una vez más, el back-end enruta la solicitud de manera adecuada, esta vez a una acción del controlador que pregunta si la consulta ya se ha realizado (no voy a entrar en detalles sobre cómo hacerlo hoy)
    1. Si se realiza la consulta, el back-end devuelve los resultados como JSON, por ejemplo, {'query_complete': true, 'query_results': 'somequeryresults', 'success': true, 'msg': ''}
    2. Si la consulta no se realiza, el back-end devuelve el mismo JSON estructurado pero con valores diferentes (tenga en cuenta que no necesita mantener la estructura, pero de nuevo no voy a entrar en el por qué de esto ahora), por ejemplo, {'query_complete': false, 'query_results': '', 'success': false, 'msg': ''}
    3. También podría devolver un mensaje de error utilizando la estructura anterior, donde query_complete es verdadero, pero éxito si es falso, y un mensaje lo acompaña en el parámetro msg.
  9. Una vez más, el front-end debe decidir qué hacer con los resultados:
    1. No hace nada con los resultados si la consulta aún no se ha realizado.
    2. Representa los resultados en el lugar apropiado si la consulta se completa con éxito
    3. Le dice al usuario que hay un error cuando la consulta ha fallado, por cualquier razón

¡Espero que esto ayude!

Related Content

¿Qué significa "back end" en el desarrollo de software?

Validé mi formulario de contacto en el front-end. ¿Tengo que hacer algo en el back-end ahora?

¿Podría usar Node.js como back-end de un sitio web?

¿Existe una empresa de alojamiento que no solicite los datos de mi tarjeta de crédito?

¿Cómo puede un desarrollador de back-end convertirse en un desarrollador móvil competente?

“Con gran dificultad” sería la respuesta más simple.

Hay un ciclo de solicitud-respuesta.

El navegador emite una solicitud HTTP al servidor, el servidor realiza alguna función (a menudo con la base de datos) y devuelve una respuesta al navegador.

Hay varias formas en que los datos pueden codificarse para la transferencia entre los dos. Normalmente, uso el protocolo AJAX (Asynchronous JavaScript and XML) con los datos codificados en formato JSON en lugar de XML.

Mantener todo sincronizado entre el cliente y el servidor requiere mucha reflexión y planificación cuidadosas.

La solución cliente-servidor basada en web más elegante que conozco es la utilizada por el marco Vaadin. En Vaadin, toda la codificación se realiza en un solo lenguaje, Java, y no hay distinción entre los elementos del lado del cliente y del lado del servidor.

Entonces, por ejemplo, en su código, podría recuperar cierta información de la base de datos y simplemente colocar los datos en un widget del lado del cliente sin ningún conocimiento de que el lado del cliente (navegador) y el lado del servidor (base de datos) se están ejecutando diferentes máquinas separadas por cientos de kilómetros.

Por supuesto, detrás de escena, el marco Vaadin se comunica intensamente entre las dos máquinas para mantener todo sincronizado. Pero todo esto es transparente para el programador.

Prefiero codificar en Ruby y a menudo necesito una biblioteca GUI más capaz que la que está disponible con Vaadin.

Es por eso que estoy desarrollando el marco Rails Express.

Tome el poder del marco Ruby-on-Rails, agregue la bondad de estilo Vaadin mezclada con un poco de magia antigua de Smalltalk y el desorden cliente-servidor desaparece.

Vanco Ordanoski

Creo que la forma más directa de explicarlo es a través de un ejemplo:

  1. La plantilla html codificada por el desarrollador front-end:

    Hola, Nombre Apellido

  2. La plantilla html modificada por el desarrollador de back-end, para que el servidor pueda interpretarla:

    Hola, {{user.name}} {{user.surname}}

  3. La salida:
    Hola joni giuro

Cuando el desarrollador de back-end implementa su parte, agrega esas llaves en la plantilla que le dicen al servidor que debe buscar datos de la base de datos y completarlos con el nombre y apellido reales. La sintaxis que mostré es en realidad el lenguaje de plantilla de Django, cada framework / lenguaje de back-end usa el suyo.

Por supuesto, están sucediendo muchas más cosas para buscar de forma segura el nombre y apellido correctos, pero creo que esto podría ayudarlo a entender.

Vanco Ordanoski

1 acrónimo: API, o en otras palabras, interfaz de programación de aplicaciones. Piense en una API como un software siempre activo que se encuentra en un servidor, que actúa como la interfaz entre el front-end, la aplicación web javascript en el navegador en este ejemplo y otro código que manipula datos y accede a una base de datos. El acceso a la API desde el front-end de JavaScript se realiza a través del protocolo HTTP. En el caso de una aplicación web, la API devuelve JSON, un formato de datos específico para transferir información específica. La inserción de datos en la API también se realizará generalmente con JSON.

¿Por qué JSON? Porque es mucho más fácil de tratar que XML. Con XML, también debe especificar la estructura de datos en un archivo separado antes de presentar los datos, mientras que con JSON, simplemente lo estructura e incluso hay un método que convierte una variable en JSON en JavaScript.

Sí, el back-end se puede construir con Java o Python, pero también he visto un back-end construido con bibliotecas de JavaScript, específicamente, NodeJS. Cada vez más, hay desarrolladores que crean toda la aplicación front-end y también los servicios back-end de los que depende la aplicación web, ya que muchas veces, el back-end no hace mucho más que acceder a una base de datos.

Justen Robertson

Una transacción típica va más o menos así.

  1. Un navegador se conecta a un servidor.
  2. Ese servidor envía el front-end al navegador.
  3. A partir de ahí, el front-end explica cómo debe comunicarse el navegador con el servidor.

¡Estás absolutamente en lo correcto! El back-end configura una serie de funciones, y el front-end espera que estén allí y funcionen correctamente.

Siempre encuentro que aprendo mejor cuando veo un ejemplo, así que con eso en mente comencemos con un ejemplo.

Digamos que tenemos un sitio web de nutrición personal que le muestra cuántas calorías han comido sus amigos hoy para que pueda burlarse de ellas. Tendrá un botón que recoge las últimas métricas, por lo que puede elegir cuál de esos “gordos” debe intimidar para sentirse mejor sobre su dolorosa infancia. ¿Suena bien?

Así que ahora tenemos un front-end básico construido. Esto es bueno. El botón es todo verde y bonito … Y está construido usando HTML y CSS, pero ¿cómo lo llevamos a los navegadores de otras personas, y también, cómo lo hacemos para que el botón pueda tomar nuestras “métricas grasas”?

Simple construimos un servidor de fondo. Nuestro servidor de fondo tendrá dos rutas:

  • / home: envía este botón al navegador junto con el código JavaScript que recuperará los datos de la segunda ruta cuando se presiona el botón y encontrará una manera de mostrar visualmente la información que recibe.
  • / api / getUserMetrics : envía las métricas grasas al navegador cuando se llama.

Bueno, ahora tenemos un sitio web construido! ¿Qué sucede cuando un usuario se conecta?

Usuario: Google “¿Cómo me convierto en un acosador?”, Y encuentra un enlace a nuestro sitio.

Usuario: hace clic en el enlace que abre ” https://www.healthylifestyles.com/home&quot ;.

Back-end: recibe la solicitud y envía la interfaz de usuario (botón) y JavaScript al navegador.

Usuario: hace clic en el botón.

Código Javascript (front-end): detecta el clic y solicita información de ” https://www.healthylifestyles.com/api/getUserMetrics&quot ;.

Back-end: envía información del usuario hacia adelante.

Código JavaScript (front-end): muestra información en la página.

Wallah ~!

¡Perfecto! ¿Estás listo para ir de cero a uno? ¿Estás listo para hacer millones? ¡Elon Musk, mejor cuidado!

Visite nuestro nuevo sitio web: https://www.healthylifestyles.com/home

Gwen Rivet

Lo que ha descrito (primero el backend, luego el frontend) es un enfoque tradicional.

Sin embargo, acabo de hacer exactamente lo contrario. He creado una aplicación html / js completa sin backend. todos los datos fueron codificados en el cliente (archivos json simples). Le mostré el prototipo funcional al cliente, implementé sus comentarios y cuando estuvieron satisfechos con la aplicación, implementé el backend.

Esto se llama primer enfoque de interfaz de usuario o diseño impulsado por UX y se debe preferir hoy en día. Con este enfoque, no está limitado al diseñar la interfaz de usuario y, por lo tanto, puede satisfacer mejor los requisitos o comentarios de su cliente. Backend solo sirve tu interfaz de usuario.

Cuando comienza con el back-end, su interfaz de usuario está limitada con el back-end y casi seguro terminará en situaciones en las que no podrá implementar algo en la interfaz de usuario que no esperaba al diseñar el back-end. Y créanme, siempre habrá alguna solicitud de cambio cuando su cliente vea la aplicación en funcionamiento. No importa cuán detallada sea la especificación o los requisitos iniciales.

Gwen Rivet

Las aplicaciones front-end se ejecutan en su navegador. Y las aplicaciones de fondo se ejecutan en un servidor remoto. Entonces, dado este hecho, al igual que cualquier otra aplicación cliente-servidor, la única interacción verdadera entre los dos está ocurriendo en la red, en forma de solicitudes y respuestas HTTP.

Claro, en muchos proyectos tendrá las vistas HTML ubicadas lado a lado con el código de fondo (por ejemplo, Ruby on Rails tiene el directorio de vistas al lado del directorio de modelos y controladores). Pero eso no cambia que esta vista HTML se represente, interprete y que cualquiera de los códigos Javascript que contiene también se ejecute en el navegador . Lo único que está haciendo el back-end con estas vistas es enviarlas al navegador y usar HTTP.

Entonces esto es cierto para todo tipo de aplicaciones web:

  • Un caso de blog simple: cuando escribe la URL de una publicación específica, su navegador está haciendo una solicitud HTTP al back-end. El back-end devuelve una respuesta HTTP que contiene el código HTML interpretado por el navegador. La única interacción entre los dos bordes es el flujo HTTP.
  • Una aplicación de una sola página, con tecnología AJAX: aquí es aún más claro que la única interacción es HTTP. La interfaz de usuario front-end con Javascript (o podría ser cualquier aplicación web, móvil o de escritorio en realidad) envía solicitudes HTTP al back-end para leer, crear, actualizar o eliminar datos. El back-end devuelve respuestas HTTP que contienen la información necesaria para que la UI / aplicación web cambie su estado, muestre datos al usuario, etc.

Por lo tanto, al final, HTML, CSS y Javascript nunca interactúan con su código de fondo. Es cierto que a veces puede usar plantillas, donde el código de fondo está reescribiendo y generando algo de HTML antes de enviarlo al navegador, pero después de eso, no hay más interacción que las simples solicitudes de red.

Gwen Rivet

Suponiendo que está hablando, por ejemplo, de un blog:

Cuando visita por primera vez un sitio web, en realidad es la url en combinación con el navegador que realiza la solicitud y no el html. Una llamada solicitud GET se envía desde el navegador a un servidor web. Este servidor web lee lo que está en la url y los encabezados de esta solicitud y comienza a enrutar esta solicitud a un código específico del servidor.

Tradicionalmente, el código del servidor es responsable de la santificación, validación e interpretación de los datos enrutados. Imagine que abre un enlace a un artículo específico. El dominio vincularía sus datos de solicitud al servidor correcto donde la uri (/ articles / some-article) vincularía sus datos de solicitud a un componente específico. El enrutador lo vinculará en este caso a un componente que se encarga de cargar artículos.

El componente en sí buscará los datos del artículo de una base de datos y luego completará una plantilla html en el servidor con los datos de ese artículo. Cuando se complete la plantilla html, responderá al navegador con este html.

El navegador interpretará el html y comenzará a cargar referencias como archivos javascript, imágenes y archivos css. Luego construye un llamado DOM y pinta la página usando css.

Por supuesto, esto es una simplificación. En realidad hay mucho más que hacer. Este es el enfoque tradicional que utilizan los sistemas de blogs populares como WordPress y Joomla.

Vanco Ordanoski

Los sistemas de TI usan interfaces para interactuar. Una interfaz es una dirección donde un sistema puede hacer preguntas a otro y obtener respuestas.

Para los sitios web, las interfaces más comunes se denominan API. En sitios web modernos, funciona de la siguiente manera:

La interfaz es como un programa que se ejecuta en el navegador del cliente. Está codificado en javascript para la parte “inteligente”, y en html / css para la parte “display”.

El backend es un programa que se ejecuta en un servidor. Se puede codificar en varios idiomas, siendo los más comunes php, java o python.

Para comunicarse, el servidor ofrece una API, que realmente es un conjunto de direcciones web que dan respuestas específicas. Los “lenguajes” más comunes para esta interacción son JSON (notación de objetos JavaScript) y XML (lenguaje de marcado extensible). Estos no son lenguajes de codificación sino formas más estandarizadas de describir datos. Ejemplos de llamadas a API pueden ser:

http://www.website.com/api/userinfo/123 devolvería la información sobre el usuario 123

http://www.website.com/api/createuser/123/password crearía el usuario “123” con la contraseña “contraseña”

y así sucesivamente (es una versión simplificada de cómo funciona realmente, pero da la idea de los géneros).

De esta manera, el frontend y el backend están claramente separados, y un desarrollador y otro pueden trabajar en un sitio web al mismo tiempo. Lo único que debe definirse en común es la API: las diferentes llamadas que se pueden hacer y las respuestas que cada una da.

Daine Lindley Mawer

En aplicaciones web, el término “front end” se refiere al código ejecutado en el navegador y “back end” al código que se ejecuta en el servidor web. El front-end a menudo se llama lado del cliente (como en el navegador es el cliente) y el back-end como lado del servidor.

Los navegadores (por ahora) se pueden programar en JavaScript, utilizando HTML (con sus extensiones) para presentación y CSS para diseño.

El back-end es mucho más versátil, se puede programar en muchos idiomas diferentes, siendo el más popular PHP, Ruby, ASP-dot-NET, JavaScript, etc.

La técnica principal que se utiliza para la comunicación entre los extremos frontal y posterior es AJAX, abreviatura de JavaScript asíncrono y XML.

La premisa de AJAX es relativamente simple: abre un “canal” desde el cliente al servidor y envía un “mensaje” a través de algunos de los métodos HTTP: POST, GET, PUT y DELETE. Este mensaje es exactamente el mismo que los que se escriben interactivamente en la línea de dirección del navegador. Por ejemplo, cuando google JavaScript, esto es lo que ve en la línea de dirección (espacio agregado antes de .com, porque Quora “traduce” automáticamente los enlaces): https://www.google .com /? Q = javascript

Este mensaje es recibido por el servidor web e interpretado. El servidor web luego llama al código que se está ejecutando en el lado del servidor y la respuesta se devuelve.

El navegador recibe la respuesta, llama al controlador de devolución y desde allí se hace cargo de JavaScript. El “controlador de devolución” es un concepto muy importante en el esquema. Eso significa que el mensaje se puede enviar al servidor sin esperar la respuesta; simplemente puede asignar un controlador de devolución para que se encargue de la respuesta cuando llegue.

Esta técnica se llama asíncrona, porque no hay que esperar. Como consecuencia (muy) importante, esto significa que el navegador no se “congela” al esperar la respuesta del servidor. El usuario sigue navegando, y la magia ocurre en segundo plano …

Hay varias bibliotecas de JavaScript que simplifican este proceso: jQuery, Dojo, Mootools y otros, por lo que el programador puede concentrarse en utilizar esta técnica sin demasiados problemas.

Vignesh Sankaran

Hay dos formas principales en que el backend y el frontend interactúan: primero, en el HTML servido al cliente en la primera carga de la página, y segundo a través de solicitudes de JavaScript asincrónicas. Hay algunas excepciones a esto (por ejemplo, si está utilizando un complemento de navegador para servir su código, como a través de Java o Flash), y algunas técnicas menos utilizadas (por ejemplo, sockets web), pero podemos dejarlas de lado por ahora y enfocarnos en los casos mas tipicos.

Entonces, interacción número uno: la solicitud de página inicial. Durante este paso, el navegador de su usuario envía una solicitud a su servidor para una página (generalmente después de seguir un enlace o escribir la dirección de su sitio web). Su pila de back-end (que generalmente incluye el software del servidor web, el código de back-end y la base de datos) reunió un documento HTML, junto con CSS y Javascript asociados, y lo envió de vuelta al usuario.

El HTML servido durante este paso, junto con todos los CSS y JS, es lo que usted consideraría un código “front-end”, pero lo más probable es que la parte HTML haya sido generada parcial o completamente por su código de back-end. El HTML frontend que le proporciona su nuevo diseñador deberá integrarse con el código de back-end para que este paso suceda. Esto generalmente implica cortar el código del diseñador en pedazos pequeños y reorganizarlos directamente en el código de fondo, o crear una plantilla marcándola con tokens especiales que el código de fondo reemplaza con su contenido final.

Interacción número dos: solicitudes asincrónicas. Esto sucede cada vez que se solicita contenido nuevo de su servidor sin volver a cargar una página o seguir un enlace. Por ejemplo, cuando se desplaza hacia abajo en Facebook o Pinterest y se carga nuevo contenido sin recargar la página, esto se realiza mediante una solicitud asincrónica. A veces, estos se sirven como fragmentos de HTML y funcionan básicamente de la misma manera que antes, pero otras veces se sirven como datos sin procesar, y se espera que el código frontend sepa cómo interpretarlo y colocarlo en la página. En el último caso, la interfaz interactúa con una API en el servidor; su código de interfaz de usuario recién creado proporcionado por el diseñador deberá ser adaptado por un desarrollador de interfaz para comunicarse correctamente con sus API de back-end.

De todos modos, esa es una descripción básica de la integración típica del sitio web. La versión corta es: necesitará al menos un desarrollador que comprenda su pila web para ayudarlo a integrar el nuevo diseño, incluso si el diseñador le proporciona un código frontend completamente integrado. Si su relación con su desarrollador original se ha vuelto hostil, esto puede complicarse, pero de lo contrario serían las primeras personas con las que hablar sobre la integración de un nuevo diseño.

Mario Peshev

Varias formas, pero realmente se reduce a estos dos que operan en un ciclo bidireccional con cada clic o carga de URL:

  1. El back-end genera el front-end como corresponde a la URL solicitada.
  2. Cada clic en cualquier enlace o botón de front-end (en una aplicación web típica) activa un script de back-end para hacer algo (cargar la página siguiente e imprimir el código de front-end).

¿Tienes un formulario web? Está PUBLICANDO en el back-end, que hace lo suyo, y luego escupe el código de front-end sobre su canal de salida.

¿Tienes una función AJAX? Está pidiendo un (con suerte) pequeño script de fondo para sus actualizaciones de datos, y / o emitiendo comandos que se envían a una función de fondo.

¿Tienes scripts cron generando informes? Los scripts cron son back-end; los informes son front-end o back-end, dependiendo de si están destinados a sus clientes o su personal, y también dependiendo un poco de la terminología de su tienda. (La “sección de administrador” o “intranet” también se suele llamar back-end).

Cuando hablamos de la separación entre la presentación (front end) y la lógica (back end), esa terminología hace que casi todos los “guiones front-end” sean tanto front-end como back-end; el script hace su trabajo de “back-end” en un lenguaje del lado del servidor, y luego genera código de front-end (HTML, etc.).

Daine Lindley Mawer

El protocolo HTTP. Es lo que realmente lleva los mensajes entre el front-end y el back-end. Pones una URL en tu navegador, has hecho una solicitud HTTP GET. El back-end devuelve el front-end en respuesta: obtienes el front-end para Google.com. escribe un término de búsqueda y presiona el botón Ir, se activa una solicitud HTTP POST, enviando su término de búsqueda al back-end. El back-end procesa la solicitud y devuelve un nuevo front-end.

Con Ajax, la única diferencia es que, en lugar de devolver un front-end completamente nuevo, solo devuelve los datos que solicitó, dejando el antiguo front-end en su lugar.

Front-end o back-end, vale la pena entender el protocolo HTTP, te hará la vida mucho más fácil.

Felipe Suárez

En cierto sentido tienes razón. Para entender cómo funciona todo, comencemos con el backend. Por lo general, se requiere un lenguaje de fondo como PHP para ejecutarse en el servidor. PHP tiene la capacidad de realizar funciones que utilizan el principio CRUD (Crear, Actualizar, Eliminar) PHP puede usar estos “verbos” para interactuar con una base de datos, por ejemplo, crear registros / datos, actualizar datos o eliminar datos. Este proceso puede ocurrir de varias maneras, como iniciar sesión, cerrar sesión, actualizar la información del usuario a través de una interfaz de perfil o escribir / publicar una publicación de blog.

El front-end le permite proporcionar una especie de interfaz para que el usuario interactúe con estas funciones de una manera mucho más gráfica. Es por eso que se llaman GUI – Interfaz gráfica de usuario. Si tiene en cuenta este proceso, debería ser mucho más fácil comprender qué sucede con las aplicaciones web.

Gwen Rivet

Por lo general, el front-end se usa para fines de presentación . El back-end es lo que alimenta el motor y realiza la computación requerida para enviar los datos al cliente.

El front-end y el back-end interactúan de dos maneras:

  1. Los datos procesados ​​por el back-end (lenguaje de programación que habla con la base de datos y los cervices de terceros) generan HTML y cargan los activos que hacen que el resultado sea fácil de usar para el visitante
  2. El visitante interactúa con el diseño completando un formulario o haciendo clic en un botón / enlace que activa otro evento a través de la plataforma HTTP que vuelve al paso 1)

El front-end se basa en los requisitos de diseño y depende de los datos entrantes. El back-end, por otro lado, tiene un conjunto limitado de instrucciones (características) y rutas que activan partes del algoritmo para calcular datos, obtener información de la base de datos, almacenar contenido nuevo o alterar el comportamiento existente de la aplicación.

Felipe Suárez

Ellos hablan”. La forma tradicional era que los formularios se enviarían y el back end enviaría páginas HTML completamente nuevas. En estos días, el back-end produce una página inicial y luego JSON (normalmente) o XML (a veces) se envía de un lado a otro en respuesta a las acciones del usuario en el front-end.

Ejemplo, presiono un botón con la etiqueta “Agregar usuario”, una solicitud va a un servicio / usuario / agregar tranquilo, el backend responde con {estado: ok} y el código de JavaScript muestra una respuesta positiva en la interfaz de usuario.

Vanco Ordanoski

Cuando solo hay un desarrollador al que realmente no le preocupa qué hacer primero, debe hacer lo que debe hacerse para finalizar el proyecto.

En un equipo, los desarrolladores se especializan en diferentes áreas y usted necesita maximizar la productividad. Esto significa que generalmente inicia el desarrollo front-end después de que el back-end está terminado.

En cuanto a cómo están conectados, generalmente me siento en una reunión donde decidimos cómo deberían ser los puntos finales.

Aquí hay un ejemplo de esto: PM dice “hey, tenemos un nuevo proyecto llamado Duck Hunt donde tienes que cazar patos”. El siguiente paso es elegir tecnología: php e ios. Luego piensas “hmm, quiero almacenar toda la información del usuario completa con puntaje de tiro, tiempo jugado y otros” y esto significa que la aplicación ios necesita enviar los datos requeridos en un momento determinado a un punto final específico. El servidor necesita almacenar los datos y quizás devolverle un resultado de qué tan bien se compara con otros jugadores.

Daniel Turan

Básicamente es a través de funciones dentro de una clase en su back-end, una clase que a menudo se conoce comúnmente como ” Controlador ”

Estas funciones funcionan como cualquier otra función, reciben parámetros, pueden ejecutar código, llamar a otras funciones dentro de ellas y al final devuelven cosas …

So how do you call these functions that are written in your back end language via front-end? With URLs of course. But instead of writing the URLs directly in the html like you use javascript or razor or some kind of helper that knows about this classes and their functions. The functions inside this special class named “Controller” are also commonly known as “ Actions ”.

Since Actions are just functions you can pass parameters to them, how? Easy, with the URL… have you ever seen urls like “somesite.com/productsdetails/154”? That “154” right there is usually a parameter for an action inside a controller (most likely the Id of the product in my example).

So that’s how the front-end sends data to the back end, but how does it receive it? Well, actions are just functions as I said, so they can return stuff which is often as a minimum an URL (remember the call of the function was inside a link, so it has to go somewhere!) But, of course they can also return data from the back end, and this is often called a Model or a ViewModel , and details vary but you can show or manipulate this data with the front end using helpers like razor or javascript (or a javascript framework).

In the surface, that’s about it, the front end knows about URLs so it communicates only with URLs… the back end knows about functions and classes so it receives parameters for its functions (encoded in URLs) and returns objects which translate in the end to URLs too!

(Of course there is also Ajax, http GET, POST, there are SPAs frameworks and way more details to know, I tried to explain everything as simple as possible)

Daniel Turan

via TCP/IP :v *rolls drums*

But in all seriousness, the communication goes through several layers of abstraction:

  1. JavaScript sits on top of the browser, which can do XML HTTP calls.
  2. These calls can also be asynchronous, which means they have their own timings. Now this is an interesting concept in JavaScript since its not a multi-thread language, so the async part is kinda emulated, but its very much there. These are called AJAX, which stands for async XML HTTP calls
  3. Then comes the service protocol. This used to be a SOAP service which would require message envelopes, signatures, types etc. These used to spit out XML messages (hence the XML HTTP). Nowadays we use RESTful APIs, which basically encourage you to use HTTP verbs ‘bought and paid for’ to describe your API instead of reinventing the wheel with SOAP message definitions
  4. Then comes the data ‘payload’. This used to be in XML format, but nowadays we’ve moved to JSON since its a simple definition of data that translates to pretty much any language.
  5. Lastly comes the JSON to language conversion. Usually via POJOs or POCOs (Plain old *insert your language here* objects).

This process of moving data from 1 technology to another is known as ETL: Extract, transform & load.

Felipe Suarez

The backend developer is looking after what’s happening behind the scene. He or she is responsible for handling the data.

Without this data, there would be no frontend.

That’s how the two are connected even though they do totally different jobs.

Léonard Hetsch

More Interesting

¿Cómo crearías un motor de búsqueda para un canal de YouTube?

¿Qué front end se recomienda con MySQL?

¿Qué es el CMS, o el back-end, parte de Quora?

¿Cuáles son las principales diferencias entre PHP y Node.js en el desarrollo de backend?

¿Qué lenguaje de programación es mejor para el back-end de un sitio web de finanzas?

¿Cuál es mejor pagado: un desarrollador front-end, back-end o full-stack?

Cómo decidir qué idioma y marco de back-end usar para su proyecto

Estoy pensando en mudarme a otro país, soy un desarrollador con experiencia en backend y frontend. Me encantan las startups. ¿Cuál es el mejor lugar para ir?

¿Es más fácil ser un desarrollador front-end o backend independiente?

¿Cuáles son las opciones para las pruebas de automatización de back-end de Node.js?

¿Cómo interactúan los desarrolladores front-end y back-end cuando compilan una aplicación?

Alguien dijo que un desarrollador de software profesional puede cambiar de backend a frontend, de móvil a desarrollo web en 1 o 2 días, ¿es cierto?

¿Es una mala idea aprender desarrollo web front-end y back-end al mismo tiempo?

¿Cuál es el papel del desarrollador de back-end?

¿Qué es más difícil de crear, el front-end del sitio web o el back-end?