Asumiré en la siguiente respuesta que está preguntando sobre los back-end de desarrollo web.
El back-end para una aplicación web recibe una solicitud de la web, con mayor frecuencia, de la siguiente manera:
El servidor web (daemon, como Apache o NginX) recibe una solicitud en un puerto determinado a un dominio o IP determinado. Utiliza esta información para decidir qué hacer con la solicitud, averiguar, ¿es una solicitud que entiendo? Si no, emite un 404. ¿Es esta una solicitud que debería ser de acceso público? Si no, emite un 403. Si identifica la solicitud (por ejemplo, yourwebhost.com en el puerto 80), puede enrutarla adecuadamente. Todos los lenguajes de back-end utilizan un método de comunicación que va del demonio del servidor web a su aplicación.
- ¿Qué es lo mejor / lo peor de trabajar en Facebook?
- ¿Cuál es la diferencia entre documentación y comentarios durante la programación?
- ¿Qué equipo tiene más posibilidades de ser llamado a una ubicación en el sitio desde una ubicación en alta mar en una empresa de servicios típica: un equipo de control de calidad o un equipo de desarrollo, y por qué?
- ¿Qué es mejor, VIT Vellore, MIT Manipal o SRM? ¿Por qué?
- ¿Cuál es el proceso de entrevista en Amazon para un ingeniero de software?
Este método de comunicación podría estar integrado en un módulo para Apache (por ejemplo, mod_php, o mod_proxy_ajp, o mod_wsgi), o podría ser un demonio independiente, como el demonio uWSGI. Este módulo o binario independiente tiene su propio oyente en un socket dado, al cual el servidor web comunica la solicitud. Este módulo o binario independiente también es responsable de montar la aplicación, subprocesos / procesos e iniciar un intérprete en cada uno de estos subprocesos / procesos. Esto es cierto si estamos hablando de Java / J2EE (que se ejecuta con Tomcat, por ejemplo), Ruby (que se ejecuta a través de Passenger), Python (que se ejecuta a través de uWSGI) o PHP.
El servidor de aplicaciones también puede ser independiente (aunque esto nunca se recomienda para configuraciones de producción / empresa). Como ejemplo, Tomcat puede ejecutarse solo, al igual que uWSGI o gUnicorn para Ruby.
Una vez que el servidor de aplicaciones recibe una solicitud, utiliza el enrutador de URL para su marco (por ejemplo, routes.rb para aplicaciones Rails o urls.py para aplicaciones Django), que pasa por un proceso similar al servidor web, haciendo coincidir la solicitud con un patrón / recurso que reconoce Al igual que con el servidor web, si la solicitud no se entiende o está prohibida, el servidor de aplicaciones emite una respuesta 404 o 403, respectivamente, de vuelta al servidor web. Si se reconoce la respuesta, se pasa a un controlador para su procesamiento.
El controlador es responsable de la lógica de negocios, y actúa como el orquestador de los datos y trabaja en esos datos, ya sea que eso implique un procesamiento posterior en tareas en segundo plano, actualizaciones / solicitudes de bases de datos, etc. El controlador es responsable de devolver algo al consumidor. Esto podría ser tan simple como una respuesta 200 (OK) sin cuerpo al consumidor, o podría representar HTML o devolver JSON o XML para que el cliente los interprete como mejor le parezca.