{"id":34140,"date":"2019-10-31T21:56:35","date_gmt":"2019-10-31T18:56:35","guid":{"rendered":"https:\/\/prohoster.info\/blog\/printsipy-razrabotki-sovremennyh-prilozhenij-ot-nginx-chast-1\/"},"modified":"2019-10-31T21:56:35","modified_gmt":"2019-10-31T18:56:35","slug":"printsipy-razrabotki-sovremennyh-prilozhenij-ot-nginx-chast-1","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/printsipy-razrabotki-sovremennyh-prilozhenij-ot-nginx-chast-1","title":{"rendered":"Principios de desarrollo de aplicaciones modernas de NGINX. Parte 1","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Hola, amigos. En la v\u00edspera del lanzamiento del curso <noindex><a rel=\"nofollow\" href=\"https:\/\/otus.pw\/h4Ez\/\">\u00abDesarrollador Backend en PHP\u00bb<\/a><\/noindex>, tradicionalmente compartimos con ustedes la traducci\u00f3n de un material \u00fatil.<\/p>\n<p>El software resuelve cada vez m\u00e1s tareas cotidianas, volvi\u00e9ndose cada vez m\u00e1s complejo. Como dijo una vez Marc Andreessen, est\u00e1 absorbiendo el mundo. <\/p>\n<p><img decoding=\"async\" alt=\"Principios de desarrollo de aplicaciones modernas de NGINX. Parte 1\" src=\"\/wp-content\/uploads\/928924e3036beaac518dd4a2674a8a30.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nComo resultado, en los \u00faltimos a\u00f1os, los enfoques para el desarrollo y la entrega de aplicaciones han cambiado significativamente. Ha habido desplazamientos de escala tect\u00f3nica que han llevado a la aparici\u00f3n de un conjunto de principios. Estos principios han resultado \u00fatiles en la formaci\u00f3n de equipos, dise\u00f1o, desarrollo y entrega de su aplicaci\u00f3n a los usuarios finales. <noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Los principios pueden resumirse de la siguiente manera: <i>la aplicaci\u00f3n debe ser peque\u00f1a, de red y tener una arquitectura orientada al desarrollador<\/i>. Bas\u00e1ndose en estos tres principios, puede crear una aplicaci\u00f3n s\u00f3lida y completa que pueda ser entregada r\u00e1pida y seguramente al usuario final, adem\u00e1s de ser f\u00e1cilmente escalable y extensible.<\/p>\n<p><img decoding=\"async\" alt=\"Principios de desarrollo de aplicaciones modernas de NGINX. Parte 1\" src=\"\/wp-content\/uploads\/9116869a53fb6cf89d92f1d507d7904f.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nCada uno de los principios propuestos tiene una serie de aspectos que discutiremos para mostrar c\u00f3mo cada principio contribuye a alcanzar el objetivo final, que es la entrega r\u00e1pida de aplicaciones confiables que sean f\u00e1ciles de mantener y usar. Compararemos los principios con sus opuestos para aclarar qu\u00e9 significa, por ejemplo, \u00abAseg\u00farese de que est\u00e1 utilizando el <i>principio de peque\u00f1a escala<\/i>\u00bb.<\/p>\n<p>Esperamos que este art\u00edculo lo motive a utilizar los principios propuestos para construir aplicaciones modernas que proporcionen un enfoque unificado de dise\u00f1o en el contexto de un conjunto de tecnolog\u00edas en constante crecimiento. <\/p>\n<p>Al aplicar estos principios, descubrir\u00e1 que est\u00e1 utilizando las \u00faltimas tendencias en el desarrollo de software, incluido el enfoque <noindex><a rel=\"nofollow\" href=\"https:\/\/www.nginx.com\/blog\/tag\/devops\/\">DevOps<\/a><\/noindex> para el desarrollo y entrega de aplicaciones, el uso de contenedores (por ejemplo, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.nginx.com\/blog\/tag\/docker\/\">Docker<\/a><\/noindex>) y marcos para la orquestaci\u00f3n de contenedores (por ejemplo, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.nginx.com\/blog\/tag\/kubernetes\/\">Kubernetes<\/a><\/noindex>), el uso de microservicios (incluida la Arquitectura de Microservicios <noindex>NGINX<\/noindex> y <noindex><a rel=\"nofollow\" href=\"https:\/\/www.nginx.com\/blog\/what-is-a-service-mesh\/\">la arquitectura de red<\/a><\/noindex> para aplicaciones de microservicios.<\/p>\n<p><b>\u00bfQu\u00e9 es una aplicaci\u00f3n moderna?<\/b><\/p>\n<p>\u00bfAplicaciones modernas? \u00bfConjunto moderno? \u00bfQu\u00e9 significa exactamente \u00abmoderno\u00bb? <\/p>\n<p>La mayor\u00eda de los desarrolladores solo tienen una idea general de qu\u00e9 constituye una aplicaci\u00f3n moderna, por lo que es necesario proporcionar una definici\u00f3n clara de este concepto.<\/p>\n<p>Una aplicaci\u00f3n moderna admite varios clientes, ya sea una interfaz de usuario en la biblioteca JavaScript React, una aplicaci\u00f3n m\u00f3vil para Android o iOS, o una aplicaci\u00f3n que se conecta con otra a trav\u00e9s de API. Una aplicaci\u00f3n moderna implica la existencia de un n\u00famero indefinido de clientes para los cuales proporciona datos o servicios.<\/p>\n<p>Una aplicaci\u00f3n moderna proporciona una API para acceder a los datos y servicios solicitados. La API debe ser inmutable y constante, en lugar de estar escrita espec\u00edficamente para una solicitud concreta de un cliente espec\u00edfico. La API est\u00e1 disponible a trav\u00e9s de HTTP(S) y proporciona acceso a toda la funcionalidad disponible en la GUI o CLI. <\/p>\n<p>Los datos deben estar disponibles en un formato com\u00fan y compatible, como JSON. La API proporciona objetos y servicios de manera clara y organizada; por ejemplo, las API RESTful o GraphQL ofrecen una interfaz adecuada.<\/p>\n<p>Las aplicaciones modernas se construyen sobre una pila moderna, que es aquella que admite tales aplicaciones. Esta pila permite al desarrollador crear una aplicaci\u00f3n con una interfaz HTTP y puntos finales API bien definidos con facilidad. El enfoque elegido permitir\u00e1 a su aplicaci\u00f3n recibir y enviar datos en formato JSON sin esfuerzo. En otras palabras, la pila moderna se alinea con los elementos de la aplicaci\u00f3n de doce factores. <noindex><a rel=\"nofollow\" href=\"https:\/\/www.nginx.com\/blog\/microservices-reference-architecture-nginx-twelve-factor-app\/\">microservicios<\/a><\/noindex>. <\/p>\n<p>Las versiones populares de este tipo de pila se basan en <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/nginxinc\/mra-photoresizer\">Java<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/nginxinc\/mra-user-manager\">Python<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/nginxinc\/mra-photouploader\">Nodo<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/nginxinc\/mra-album-manager\">Ruby<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/nginxinc\/mra-pages\">PHP<\/a><\/noindex> y <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/nginxinc\/mra-content-service\">Go<\/a><\/noindex>. La Arquitectura de Microservicios <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/nginxinc\/mra-ingenious\">NGINX<\/a><\/noindex> personifica un ejemplo de una pila moderna implementada en cada uno de los idiomas mencionados.<\/p>\n<p>Tenga en cuenta que no estamos promoviendo exclusivamente el enfoque de microservicios. Muchos de ustedes trabajan con monolitos que deben evolucionar, mientras que otros tratan con aplicaciones SOA que se expanden y evolucionan para convertirse en aplicaciones de microservicios. Algunos se dirigen hacia la implementaci\u00f3n de aplicaciones sin servidor (serverless), mientras que otros implementan combinaciones de lo anterior. Los principios expuestos en este art\u00edculo son aplicables a cada uno de estos sistemas con algunos cambios menores. <\/p>\n<p><b>Principios<\/b><\/p>\n<p>Ahora que hemos alcanzado un entendimiento com\u00fan sobre qu\u00e9 son las aplicaciones modernas y el stack moderno, es hora de sumergirnos en los principios de arquitectura y desarrollo que te ser\u00e1n de gran ayuda en la creaci\u00f3n, implementaci\u00f3n y mantenimiento de una aplicaci\u00f3n moderna.<\/p>\n<p>Uno de los principios se formula como \u00abcrea aplicaciones peque\u00f1as\u00bb, llam\u00e9moslo simplemente <i>el principio de la peque\u00f1ez<\/i>. Existen aplicaciones incre\u00edblemente complejas que consisten en una gran cantidad de componentes m\u00f3viles. A su vez, construir una aplicaci\u00f3n a partir de peque\u00f1os componentes discretos simplifica su dise\u00f1o, mantenimiento y funcionamiento en general. (Nota que dijimos \u00absimplifica\u00bb, y no \u00abhace simple\u00bb).<\/p>\n<p>El segundo principio es que podemos aumentar la productividad de los desarrolladores, ayud\u00e1ndoles a concentrarse en las funciones que est\u00e1n desarrollando, liber\u00e1ndolos de preocupaciones sobre la infraestructura y CI\/CD durante la implementaci\u00f3n. As\u00ed que, en pocas palabras, nuestro enfoque <i>est\u00e1 orientado a los desarrolladores<\/i>.<\/p>\n<p>Finalmente, todo lo que concierne a tu aplicaci\u00f3n debe estar conectado a la red. En los \u00faltimos 20 a\u00f1os, hemos avanzado enormemente hacia un futuro en red, ya que las redes se han vuelto m\u00e1s r\u00e1pidas y las aplicaciones m\u00e1s complejas. Como ya hemos determinado, una aplicaci\u00f3n moderna debe ser utilizada en red por m\u00faltiples clientes diferentes. La aplicaci\u00f3n del pensamiento en red en la arquitectura tiene ventajas significativas que se combinan bien con <i>el principio de la peque\u00f1ez<\/i> y el concepto del enfoque, <i>orientado a los desarrolladores<\/i>.<\/p>\n<p>Si al desarrollar e implementar tu aplicaci\u00f3n mantienes estos principios en mente, tendr\u00e1s una ventaja innegable en el desarrollo y la entrega de tu producto.<\/p>\n<p>Examinemos estos tres principios con m\u00e1s detalle.<\/p>\n<p><b>Principio de la peque\u00f1ez<\/b><\/p>\n<p>Es dif\u00edcil para el cerebro humano procesar una gran cantidad de informaci\u00f3n a la vez. En psicolog\u00eda, el t\u00e9rmino carga cognitiva se refiere a la cantidad total de esfuerzo mental necesario para mantener informaci\u00f3n en la memoria. Reducir la carga cognitiva sobre los desarrolladores es una prioridad, ya que de esta manera pueden concentrarse en resolver problemas, en lugar de mantener en su mente el modelo complejo actual de toda la aplicaci\u00f3n y las funciones que se est\u00e1n desarrollando. <\/p>\n<p><img decoding=\"async\" alt=\"Principios de desarrollo de aplicaciones modernas de NGINX. Parte 1\" src=\"\/wp-content\/uploads\/26df2016a46d8b82b45832fe1df9bf23.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<i>Las aplicaciones se descomponen por las siguientes razones:<\/p>\n<ul>\n<li>Reducir la carga cognitiva sobre los desarrolladores;<\/li>\n<li>Acelerar y simplificar las pruebas;<\/li>\n<li>Entregar cambios r\u00e1pidamente en la aplicaci\u00f3n.<\/li>\n<\/ul>\n<p><\/i><br \/>\nHay varias formas de reducir la carga cognitiva sobre los desarrolladores, y aqu\u00ed es donde entra en juego el principio de peque\u00f1ez.<\/p>\n<p>As\u00ed que, tres formas de reducir la carga cognitiva:<\/p>\n<ol>\n<li>Reducir los plazos que deben considerar al desarrollar una nueva funci\u00f3n: cuanto m\u00e1s corto sea el plazo, menor ser\u00e1 la carga cognitiva.<\/li>\n<li>Reducir la cantidad de c\u00f3digo en el que se trabaja al mismo tiempo: menos c\u00f3digo significa menos carga.<\/li>\n<li>Simplificar el proceso de realizar cambios incrementales en la aplicaci\u00f3n.<\/li>\n<\/ol>\n<p>\n<b>Reducci\u00f3n de plazos de desarrollo<\/b><\/p>\n<p>Volvamos a los d\u00edas en que la metodolog\u00eda <code>waterfall<\/code> era el est\u00e1ndar del proceso de desarrollo, y los plazos de seis meses a dos a\u00f1os para desarrollar o actualizar una aplicaci\u00f3n eran la pr\u00e1ctica com\u00fan. Por lo general, los ingenieros le\u00edan primero documentos relevantes, como el documento de requisitos del producto (PRD), el documento de referencia del sistema (SRD), el plan de arquitectura y comenzaban a unir todas estas cosas en un solo modelo cognitivo seg\u00fan el cual escrib\u00edan el c\u00f3digo. A medida que cambiaban los requisitos y, en consecuencia, la arquitectura, se requer\u00eda un esfuerzo considerable para informar a todo el equipo sobre las actualizaciones del modelo cognitivo. Tal enfoque, en el peor de los casos, pod\u00eda simplemente paralizar el trabajo.<\/p>\n<p>El mayor cambio en el proceso de desarrollo de aplicaciones fue la implementaci\u00f3n de la metodolog\u00eda \u00e1gil. Una de las caracter\u00edsticas principales de la metodolog\u00eda <code>agile<\/code> es el desarrollo iterativo. A su vez, esto conduce a una reducci\u00f3n de la carga cognitiva sobre los ingenieros. En lugar de exigir al equipo de desarrolladores la implementaci\u00f3n de la aplicaci\u00f3n en un largo ciclo, <code>agile<\/code> el enfoque permite centrarse en peque\u00f1os vol\u00famenes de c\u00f3digo que pueden probarse y desplegarse r\u00e1pidamente, al mismo tiempo que se obtiene retroalimentaci\u00f3n. La carga cognitiva de la aplicaci\u00f3n se ha desplazado de plazos de seis meses a dos a\u00f1os con una gran cantidad de especificaciones a una adici\u00f3n o cambio de funci\u00f3n de dos semanas, orientado a una comprensi\u00f3n m\u00e1s difusa de una gran aplicaci\u00f3n.<\/p>\n<p>El cambio de enfoque de aplicaciones masivas a funciones peque\u00f1as y espec\u00edficas que pueden completarse en un sprint de dos semanas, con una mirada hacia adelante que no excede una funci\u00f3n del pr\u00f3ximo sprint, es un cambio significativo. Esto ha permitido aumentar la productividad del desarrollo mientras se reduce la carga cognitiva, que var\u00eda constantemente.<\/p>\n<p>En la metodolog\u00eda <code>agile<\/code> se asume que la aplicaci\u00f3n final ser\u00e1 una versi\u00f3n algo modificada del concepto original, por lo que el punto final del desarrollo es necesariamente ambiguo. Solo se pueden considerar claras y precisas las entregas de cada sprint en particular.<\/p>\n<p><b>Las bases de c\u00f3digo peque\u00f1as<\/b><\/p>\n<p>El siguiente paso en la reducci\u00f3n de la carga cognitiva es disminuir la base de c\u00f3digo. Por lo general, las aplicaciones modernas son masivas; una aplicaci\u00f3n empresarial robusta puede constar de miles de archivos y cientos de miles de l\u00edneas de c\u00f3digo. Dependiendo de la organizaci\u00f3n de los archivos, las conexiones y dependencias entre el c\u00f3digo y los archivos pueden ser evidentes o, por el contrario, confusas. Incluso la depuraci\u00f3n de la ejecuci\u00f3n del c\u00f3digo puede presentar problemas, dependiendo de las bibliotecas utilizadas y de qu\u00e9 tan bien las herramientas de depuraci\u00f3n separen las bibliotecas\/packs\/m\u00f3dulos del c\u00f3digo del usuario.<\/p>\n<p>Construir un modelo mental funcional del c\u00f3digo de la aplicaci\u00f3n puede llevar un tiempo considerable y, nuevamente, imponer una gran carga cognitiva al desarrollador. Esto es especialmente cierto para las bases de c\u00f3digo monol\u00edticas, donde hay una gran cantidad de c\u00f3digo y la interacci\u00f3n entre los componentes funcionales no est\u00e1 claramente definida, y la separaci\u00f3n de los objetos de atenci\u00f3n a menudo se difumina, ya que no se respetan las fronteras funcionales. <\/p>\n<p>Una de las formas efectivas de reducir la carga cognitiva sobre los ingenieros es pasar a una arquitectura de microservicios. En el enfoque de microservicios, cada servicio se centra en un conjunto de funciones; el significado del servicio generalmente est\u00e1 definido y es claro. Los l\u00edmites del servicio tambi\u00e9n son claros; recuerde que la comunicaci\u00f3n con el servicio se realiza a trav\u00e9s de API, por lo que los datos generados por un servicio pueden ser f\u00e1cilmente transferidos a otro.<\/p>\n<p>La interacci\u00f3n con otros servicios suele estar limitada a algunos servicios de usuario y a algunos servicios del proveedor, que utilizan llamadas API simples y limpias, por ejemplo, a trav\u00e9s de REST. Esto significa que la carga cognitiva para el ingeniero se reduce significativamente. La tarea m\u00e1s complicada sigue siendo entender el modelo de interacci\u00f3n de los servicios y c\u00f3mo se producen cosas como las transacciones en varios servicios. En definitiva, el uso de microservicios reduce la carga cognitiva, disminuyendo la cantidad de c\u00f3digo, delimitando claramente las fronteras del servicio y asegurando una comprensi\u00f3n de las relaciones entre usuarios y proveedores.<\/p>\n<p><b>Peque\u00f1os cambios incrementales<\/b><\/p>\n<p>El \u00faltimo elemento del principio <i>peque\u00f1eces<\/i> \u2013 es la gesti\u00f3n de cambios. Una tentaci\u00f3n particular para los desarrolladores es mirar el c\u00f3digo base (incluso, tal vez, su propio c\u00f3digo m\u00e1s antiguo) y afirmar: \u201cEsto es una porquer\u00eda, necesitamos reescribirlo todo.\u201d A veces esa es la decisi\u00f3n correcta, y a veces no. Impone al equipo de desarrolladores la carga de un cambio global en el modelo, lo que a su vez conduce a una gran carga cognitiva. Es mejor que los ingenieros se concentren en los cambios que pueden realizar durante el sprint, para luego implementar las funcionalidades necesarias a su debido tiempo, aunque sea de manera gradual. El producto final debe parecerse a un plan preestablecido, pero con algunos cambios y pruebas para satisfacer las necesidades del cliente.<\/p>\n<p>Al reescribir grandes partes de c\u00f3digo, a veces resulta imposible realizar cambios r\u00e1pidamente, ya que entran en juego otras dependencias del sistema. Para controlar el flujo de cambios, se puede utilizar la ocultaci\u00f3n de funcionalidades (feature hiding). En principio, esto significa que la funcionalidad est\u00e1 en producci\u00f3n, pero no es accesible a trav\u00e9s de ajustes de variables de entorno (env-var) o alg\u00fan otro mecanismo de configuraci\u00f3n. Si el c\u00f3digo ha pasado por todos los procesos de control de calidad, puede estar en producci\u00f3n en un estado oculto. Sin embargo, esta estrategia solo funciona si la funci\u00f3n eventualmente se habilita. De lo contrario, solo saturar\u00e1 el c\u00f3digo y a\u00f1adir\u00e1 carga cognitiva que el desarrollador deber\u00e1 manejar para trabajar de manera productiva. La gesti\u00f3n de cambios y los cambios incrementales ayudan a mantener la carga cognitiva de los desarrolladores en un nivel manejable. <\/p>\n<p>Los ingenieros enfrentan muchas dificultades incluso al implementar funcionalidades adicionales simples. Desde la perspectiva de la direcci\u00f3n, es razonable reducir la carga innecesaria sobre el equipo para que puedan concentrarse en los elementos clave de la funcionalidad. Hay tres cosas que puedes hacer para ayudar a tu equipo de desarrolladores:<\/p>\n<ol>\n<li>Utilizar metodolog\u00edas <code>agile<\/code>, para limitar los plazos en los que el equipo debe centrarse en las funciones clave.<\/li>\n<li>Implementar tu aplicaci\u00f3n como varios microservicios. Esto limitar\u00e1 la cantidad de funcionalidades implementadas y reforzar\u00e1 los l\u00edmites que mantienen la carga cognitiva durante el trabajo.<\/li>\n<li>Prefiere cambios incrementales en lugar de grandes y pesados, modificando peque\u00f1as secciones de c\u00f3digo. Aplica la ocultaci\u00f3n de funciones para implementar cambios, incluso si no ser\u00e1n visibles inmediatamente despu\u00e9s de ser a\u00f1adidos.<\/li>\n<\/ol>\n<p>\nSi aplicas el principio de simplicidad en tu trabajo, tu equipo ser\u00e1 mucho m\u00e1s feliz, se enfocar\u00e1 mejor en la implementaci\u00f3n de las funciones necesarias y ser\u00e1 m\u00e1s probable que realice cambios de calidad m\u00e1s r\u00e1pidamente. Sin embargo, esto no significa que el trabajo no pueda complicarse; a veces, por el contrario, la implementaci\u00f3n de nuevas funcionalidades requiere modificaciones en varios servicios, y este proceso puede ser m\u00e1s complicado que en una arquitectura monol\u00edtica. En cualquier caso, las ventajas de aplicar el enfoque de simplicidad valen la pena.<\/p>\n<p>Fin de la primera parte.<\/p>\n<p>Pronto publicaremos la segunda parte de la traducci\u00f3n, pero por ahora esperamos sus comentarios y los invitamos a <noindex><a rel=\"nofollow\" href=\"https:\/\/otus.pw\/mJ6e\/\">d\u00eda de puertas abiertas<\/a><\/noindex>, que se llevar\u00e1 a cabo hoy a las 20:00.<br \/>\n<br \/>Fuente: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/otus\/blog\/452748\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0438\u0432\u0435\u0442, \u0434\u0440\u0443\u0437\u044c\u044f. \u0412 \u043f\u0440\u0435\u0434\u0434\u0432\u0435\u0440\u0438\u0438 \u0437\u0430\u043f\u0443\u0441\u043a\u0430 \u043a\u0443\u0440\u0441\u0430 \u00abBackend \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a \u043d\u0430 PHP\u00bb, \u0442\u0440\u0430\u0434\u0438\u0446\u0438\u043e\u043d\u043d\u043e \u0434\u0435\u043b\u0438\u043c\u0441\u044f \u0441 \u0432\u0430\u043c\u0438 \u043f\u0435\u0440\u0435\u0432\u043e\u0434\u043e\u043c \u043f\u043e\u043b\u0435\u0437\u043d\u043e\u0433\u043e \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b\u0430. \u041f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u043d\u043e\u0435 \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0435\u043d\u0438\u0435 \u0440\u0435\u0448\u0430\u0435\u0442 \u0432\u0441\u0435 \u0431\u043e\u043b\u044c\u0448\u0435 \u0438 \u0431\u043e\u043b\u044c\u0448\u0435 \u043f\u043e\u0432\u0441\u0435\u0434\u043d\u0435\u0432\u043d\u044b\u0445 \u0437\u0430\u0434\u0430\u0447, \u043f\u0440\u0438 \u044d\u0442\u043e\u043c \u0441\u0442\u0430\u043d\u043e\u0432\u044f\u0441\u044c \u0432\u0441\u0435 \u0441\u043b\u043e\u0436\u043d\u0435\u0435 \u0438 \u0441\u043b\u043e\u0436\u043d\u0435\u0435. \u041a\u0430\u043a \u043e\u0434\u043d\u0430\u0436\u0434\u044b \u0441\u043a\u0430\u0437\u0430\u043b \u041c\u0430\u0440\u043a \u0410\u043d\u0434\u0440\u0435\u0441\u0441\u0435\u043d, \u043e\u043d\u043e \u043f\u043e\u0433\u043b\u043e\u0449\u0430\u0435\u0442 \u043c\u0438\u0440. \u0412 \u0440\u0435\u0437\u0443\u043b\u044c\u0442\u0430\u0442\u0435 \u0432 \u0442\u0435\u0447\u0435\u043d\u0438\u0435 \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u0438\u0445 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u0438\u0445 \u043b\u0435\u0442 \u043f\u043e\u0434\u0445\u043e\u0434\u044b \u043a \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0435 \u0438 \u043f\u043e\u0441\u0442\u0430\u0432\u043a\u0435 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0439 \u0441\u0435\u0440\u044c\u0435\u0437\u043d\u043e [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-34140","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u0438\u0432\u0435\u0442, \u0434\u0440\u0443\u0437\u044c\u044f.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/printsipy-razrabotki-sovremennyh-prilozhenij-ot-nginx-chast-1\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2\" \/>\n\t\t<meta property=\"og:locale\" content=\"es_ES\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041f\u0440\u0438\u043d\u0446\u0438\u043f\u044b \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u0441\u043e\u0432\u0440\u0435\u043c\u0435\u043d\u043d\u044b\u0445 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0439 \u043e\u0442 NGINX. \u0427\u0430\u0441\u0442\u044c 1 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u0438\u0432\u0435\u0442, \u0434\u0440\u0443\u0437\u044c\u044f.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/printsipy-razrabotki-sovremennyh-prilozhenij-ot-nginx-chast-1\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T18:56:35+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T18:56:35+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Principios de desarrollo de aplicaciones modernas de NGINX. Parte 1 | ProHoster","description":"Hola, amigos.","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/printsipy-razrabotki-sovremennyh-prilozhenij-ot-nginx-chast-1","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"es_ES","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041f\u0440\u0438\u043d\u0446\u0438\u043f\u044b \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u0441\u043e\u0432\u0440\u0435\u043c\u0435\u043d\u043d\u044b\u0445 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0439 \u043e\u0442 NGINX. \u0427\u0430\u0441\u0442\u044c 1 | ProHoster","og:description":"\u041f\u0440\u0438\u0432\u0435\u0442, \u0434\u0440\u0443\u0437\u044c\u044f.","og:url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/printsipy-razrabotki-sovremennyh-prilozhenij-ot-nginx-chast-1","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:56:35+00:00","article:modified_time":"2019-10-31T18:56:35+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"34140","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-21 18:05:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:27:30","updated":"2026-01-21 18:05:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/34140","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=34140"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/34140\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=34140"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=34140"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=34140"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}