Diferencia entre frontend, backend y middleware en desarrollo web

En términos generales, la gente se refiere a la capa de presentación de una aplicación como su front end, su capa de persistencia (base de datos, por lo general) como el back end, y cualquier cosa entre como middle tier. Este conjunto de ideas a menudo se conoce como arquitectura de 3 niveles. Le permiten separar su aplicación en más fácilmente comprensible (y comprobable!) fragmentos; también puede reutilizar código de nivel inferior más fácilmente en niveles superiores.

Qué código es parte de qué nivel es algo subjetivo; los diseñadores gráficos tienden a pensar en todo lo que no es la presentación como el back-end, la gente de la base de datos piensa en todo lo que está delante de la base de datos como el front-end, y así sucesivamente.

Sin embargo, no todas las aplicaciones necesitan separarse de esta manera. Ciertamente es más trabajo tener 3 subproyectos separados que simplemente abrir index.php y get cracking; dependiendo de (1) cuánto tiempo espera tener para mantener la aplicación (2) qué tan compleja espera que la aplicación se vuelva, puede renunciar a la complejidad.

De hecho hay 3 preguntas en tu pregunta :

• Define frontend, middle y back end
• ¿Cómo y cuándo se superponen ?
• Sus cuellos de botella habituales asociados.

Lo que JB King ha descrito es correcto, pero es una versión particular y simple, donde de hecho mapeó front, middle y bacn a una capa MVC. Mapeó M hacia atrás, V hacia adelante y C hacia el medio.

Para muchas personas, está bien, ya que vienen del mundo feo donde incluso MVC no se aplicó, y podría tener llamadas directas a la base de datos en una vista.

Sin embargo, en aplicaciones web reales y complejas, de hecho tiene dos o tres capas diferentes, llamadas front, middle y back. Cada uno de ellos puede tener una base de datos asociada y un controlador.

El front-end será visible por el usuario final. No debe confundirse con el front-office, que es la interfaz de usuario para los parámetros y la administración del front. El front-end generalmente será algún tipo de CMS o plataforma de comercio electrónico (Magento, etc.)

El extremo medio no es obligatorio y es donde está la lógica de negocio. Se basará en un PIM, una herramienta MDM, o algún tipo de base de datos personalizada donde enriquezcas tus productos o tus artículos (para CMS). También será el lugar donde codificará las funciones de negocio que deben compartirse entre diferentes interfaces (por ejemplo, entre la interfaz de PC y la aplicación móvil basada en API). A veces, un ESB o una herramienta como ActiveMQ será su extremo medio

El back-end será una 3ra capa, rodeando su base de datos de origen o su ERP. Puede ser jsut la API wrting y lectura de su ERP. Puede ser su proveedor DB, si usted está haciendo e-commerce. De hecho, realmente depende de los proyectos web, pero siempre es un repositorio central. Se accederá a él a través de una llamada a la base de datos, a través de una API, o una capa de Hibernación, o una aplicación de back-end con todas las funciones

Esta descripción significa que responder a las otras 2 preguntas es no es posible en este hilo, ya que los cuellos de botella realmente dependen de lo que contengan sus 3 extremos: lo que JB King escribió sigue siendo cierto para arquitecturas MVC simples

En el momento en que se hizo la pregunta (hace 5 años), tal vez el patrón MVC aún no estaba tan ampliamente adoptado. Ahora, no hay absolutamente ninguna razón por la que el patrón MVC no se seguiría y una vista estaría vinculada a las llamadas a DB. Si lee la pregunta " ¿Hay casos en los que deben superponerse, y frontend/backend no pueden separarse?"en un sentido más amplio, con 3 componentes diferentes, entonces hay veces en que la arquitectura de 3 capas es inútil, por supuesto. Piense en un simple blog personal, no necesitará extraer datos externos o sondear colas de RabbitMQ.

Aquí hay un ejemplo del mundo real que muestra front/mid/back end.

Descripción general:

• Frontend es responsable de presentar los datos al usuario. Tenga en cuenta peculiaridad interesante que usted puede tener dos diferentes front ends asociados con un solo backend
• Backend proporciona lógica de negocio/persistencia de datos.
• El Middleware (activemq en la imagen) es responsable de system to system. integración entre backends. Por lo general, se instala como separado aplicación

Superposición:

Es posible tener superposición entre frontend y backend. Esto generalmente conduce a problemas a largo plazo con el mantenimiento y la escalabilidad de las aplicaciones. Bastante común en aplicaciones heredadas.

La mayoría de las pilas de tecnología moderna alientan a los desarrolladores a tener una separación estricta. Por ejemplo, en la imagen se puede ver que el backend del primer sistema tiene rest web service que es una clara separación alinear.

Cuellos de botella

La mayoría de los cuellos de botella en grandes son causados por la base de datos/red. Las bases de datos se encuentran en el backend. En cuanto a los problemas de red, cada conexión pasa por netowrk, por lo que cada conexión tiene potencial para ser lenta. Con un buen diseño de la aplicación, estos problemas son evitables en gran medida.

En términos de redes y seguridad, el Backend es, con mucho, el nodo más seguro (debería ser).

La porción de extremo medio, generalmente siendo un servidor web, estará algo en la naturaleza y cortada en muchos aspectos de la red de una empresa. El nodo de extremo medio generalmente se coloca en la zona desmilitarizada y se segmenta desde la red con la configuración del firewall. La mayor parte del análisis de código del lado del servidor de las páginas web se maneja en el servidor web de gama media.

Llegar al backend significa pasar por el extremo medio, que tiene un conjunto cuidadosamente diseñado de reglas que permiten / no permiten el acceso a los nummies vitales que se almacenan en el servidor de base de datos (backend).