Migración Frankenstein: enfoque independiente del marco (Parte 1)

 

 

 

  • Anuncie en la revista Smashing
  • Patrones de diseño de interfaces inteligentes, vídeo de 10h + formación UX

  • Índice
    1. Migración “buena”: reescritura completa #
    2. Migración “rápida”: migración gradual #
    3. Migración Frankenstein. Parte 1: Teoría #
      1. ¿Por qué “Frankenstein”? #
      2. Arquitectura de microservicios #
      3. Componentes web #
      4. Alcance de CSS frente a encapsulación. El estilo Shadow DOM #
    4. 1. Identificar microservicios #
      1. Refactorizar si es necesario #
      2. ¿Demasiado pequeño para un servicio? #
    5. 2. Permitir el acceso de host a alienígena #

    Algunos de nosotros preferimos trabajar con Vue, a otros les gusta React, algunos disfrutan de Angular, mientras que otros sienten que Svelte es nuestro mañana. Incluso podría ser uno de esos no tan pusilánimes que crean aplicaciones con componentes web: ¡el mundo front-end contemporáneo puede satisfacer todos los gustos! Sin embargo, ¿qué pasa si su proyecto se quedó en el pasado? ¿Qué pasa si dedicas una cantidad desproporcionada de tiempo a dar soporte a un sistema obsoleto?

     

    La respuesta típica a este problema es la migración de la aplicación. Sin embargo, todos los marcos de front-end son diferentes y, por lo tanto, los procesos de migración deberían ser ejercicios diferentes y no triviales. ¿Bien? No necesariamente. En este artículo, analizamos la “Migración Frankenstein”, que es un nuevo enfoque independiente del marco para el proceso de migración que permite utilizar el mismo mecanismo para migrar a prácticamente cualquier marco de su elección.

    La migración, según el Oxford Learner's Dictionary , es “el movimiento lento o gradual de algo de un lugar a otro”. Este término describe muchas cosas y fenómenos en nuestro mundo, tanto con tintes positivos como negativos. En el desarrollo de software, la palabra “migración”, cuando necesitamos actualizar o cambiar la tecnología en un proyecto, desafortunadamente generalmente se incluye en el último caso.

     

    “Bueno”, “Rápido”, “Barato”. Solíamos elegir sólo dos en muchas situaciones en las que necesitamos tomar una decisión, ya sea en el desarrollo, en los negocios o en la vida en general. Normalmente, la migración front-end, que es el tema principal de este artículo, no permite ni siquiera eso: lo "barato" está fuera del alcance de cualquier migración , y hay que elegir entre "bueno" o "rápido". Sin embargo, no puedes tener ambos. Típicamente.

    El monstruo de Frankenstein no tiene por qué ser necesariamente terrible. Puede ser lindo. A veces. ( Vista previa grande )

    En un intento de romper con los estereotipos, este artículo sugiere un enfoque no tan típico para la migración de aplicaciones front-end independiente del marco: la " Migración Frankenstein ". Este enfoque nos permite combinar lo “bueno” y lo “rápido” manteniendo a raya los costos de la migración.

    Sin embargo, no es una solución milagrosa. Más bien, me gusta pensar en ello como una pequeña revolución migratoria. Y como cualquier otra revolución, este enfoque podría tener efectos secundarios, problemas y personas llenas de energía para afirmar que esto no va a funcionar incluso antes de intentarlo.

    Sin duda, abordaremos los problemas potenciales de este enfoque más adelante en el artículo, pero tengan paciencia y, tal vez, todavía encuentren una o dos ideas útiles para su próxima migración.

    Además, el mismo enfoque que vamos a comentar se puede utilizar para una gama más amplia de tareas que no están directamente relacionadas con la migración:

    • Combinando diferentes partes de su aplicación , escritas en diferentes marcos. Podría resultar útil para la creación rápida de prototipos, el arranque e incluso experimentos listos para producción.
    • Desacoplar diferentes características de su aplicación para poder implementarla sin reconstruir toda la aplicación . Tal vez incluso configure sus funciones principales en el ciclo de lanzamiento más frecuente. Puede resultar útil en proyectos grandes. En particular, aquellos que ejecutan CI/CD cada vez que inserta cosas master(lo que puede llevar mucho tiempo) y ayudan a ahorrar tiempo en los lanzamientos de funciones.
    • Este enfoque podría incluso permitirle tener una política de contratación flexible : podría contratar desarrolladores inteligentes incluso si todavía no trabajan con el marco de su proyecto. Los desarrolladores pueden seguir usando herramientas y marcos con los que se sienten cómodos y aportar valor a su empresa desde el día 1 (especialmente valioso en las empresas emergentes) mientras aprenden cómo funciona su proyecto y eligen el marco de su elección.

    Sin embargo, este artículo trata sobre la migración y antes de sumergirnos profundamente en las aguas oscuras de la migración Frankenstein, veamos dónde estamos con esas alternativas de migración “ buenas ” y “ rápidas ” para ser conscientes de sus lados fuertes y débiles.

    Migración “buena”: reescritura completa #

    Por lo general, se considera que la reescritura completa es una mejor manera de migrar sus aplicaciones en términos de calidad. Tiene sentido: está escribiendo su aplicación desde cero y, por lo tanto, puede aportar toda su experiencia y sabiduría de la implementación actual a la nueva desde el principio, no como una ocurrencia tardía. Es una gran ventaja para este tipo de migración. Sin embargo, existe un problema no tan obvio con la reescritura completa.

    Para lograr esta cualidad, necesitas tiempo . A veces, mucho tiempo. Alternativamente, muchos desarrolladores se dedican exclusivamente a reescribir. No todas las empresas pueden permitirse estas opciones. Debido a esto, el escenario más adecuado para este tipo de migración es un proyecto pequeño/personal sin necesidad de desarrollar nuevas funciones todo el tiempo o un proyecto que no sea de misión crítica para su negocio.

    Para darle una perspectiva del tiempo: una vez estuve en una reescritura completa de una aplicación que tomó dos años. Aún así, durante todo este tiempo, el antiguo proyecto con todos sus errores estuvo en funcionamiento. Nadie quería tocarlo y, en cambio, se concentraban en el “nuevo y brillante”. Típicamente.

    A modo de resumen para este tipo de migración:

    VENTAJAS :

    • Calidad resultante.

    CONTRAS :

    • El tiempo necesario para hacer llegar esa calidad al usuario final;
    • La cantidad de trabajo que hay que hacer durante la reescritura completa es abrumadora, lo que dificulta estimar por adelantado el tiempo y los recursos necesarios para este tipo de migración.

    Aquellos que planean migrar pero no pueden permitirse el lujo de reescribirlo por completo debido a limitaciones de tiempo o recursos tal vez quieran considerar el siguiente tipo de migración.

    Migración “rápida”: migración gradual #

    A diferencia de la reescritura completa, la migración gradual no requiere esperar hasta que se complete la migración. En su lugar, migra la aplicación poco a poco y pone esos nuevos bits a disposición de sus usuarios tan pronto como estén listos. Llamar a este tipo de migración “rápida” es un poco exagerado, por supuesto, si hablamos de la aplicación completa, pero claramente se pueden entregar funciones separadas a los usuarios mucho más rápido. Sin embargo, también describamos los pros y los contras imparciales de la migración gradual:

    VENTAJAS :

    • Cuando se trata de entregar partes separadas de la aplicación al usuario final, la migración gradual es de hecho más rápida que la reescritura completa, ya que no necesitamos esperar a que se reescriba toda la aplicación.
    • Al entregar gradualmente bits nuevos migrados, recibimos comentarios sobre ellos (de los usuarios finales) a medida que avanzamos. Nos permite detectar errores y problemas más rápido y de una manera más aislada, en comparación con la reescritura completa, donde implementamos la aplicación migrada como un todo y podemos pasar por alto algunos problemas o errores más pequeños.

    Para comprender mejor los problemas de la migración gradual, intente instalar React en paralelo con Vue en el mismo proyecto que en la migración de Vue a React. Creo que tienes que disfrutar mucho investigando configuraciones y resolviendo errores de la consola para disfrutar de este proceso. Sin embargo, ni siquiera necesitamos profundizar tanto. Consideremos el siguiente ejemplo heredado :

     

    Los componentes, independientemente de los módulos CSS, son muy vulnerables a los estilos globales. En este ejemplo simple, tenemos al menos cuatro formas de dividir visualmente el componente Vue. ( Fuente ) ( Vista previa grande )

    Aquí, estamos integrando un componente de Vue en una aplicación Vanilla JS como en un posible escenario de migración de Vanilla a Vue. Los módulos CSS son responsables del estilo del componente Vue y brindan el alcance adecuado para sus componentes. Sin embargo, como puede ver, aunque el estilo del componente Vue indica que el subtítulo sea verde, está completamente desactivado y el ejemplo presenta hasta cuatro (pero en realidad hay muchas más) formas triviales de romper el estilo del componente.

    Además, otros estilos globales que entran en este componente de Vue pueden ampliar el aspecto de nuestro componente por completo y, aunque pueda verse como una característica en algunos proyectos, hace que las cosas sean difíciles de predecir y mantener y no es necesariamente lo que queremos. Este ejemplo revela el problema más común y difícil de abordar de la migración gradual: la parte "Cascada" de CSS puede romper componentes fácilmente.

    Este ejemplo artificialmente simplificado también revela otros grandes problemas relacionados con la migración gradual :

    • Debido a que estamos combinando dos sistemas diferentes, el resultado puede resultar muy desordenado: tenemos que soportar dos sistemas diferentes con sus dependencias, requisitos y opiniones simultáneamente en el mismo proyecto. Es posible que diferentes marcos requieran las mismas dependencias, pero en diferentes versiones, lo que genera conflictos de versiones.
    • Dado que la aplicación integrada (Vue en nuestro caso) se representa en el árbol DOM principal, el alcance global en JavaScript es propenso a conflictos: es posible que ambos sistemas quieran manipular nodos DOM que no les pertenecen.
    • Además, permítanme repetir esto, ya que llegaremos a este punto varias veces en este artículo: debido a la naturaleza global de esta integración, CSS se desborda de un sistema a otro sin mucho control, contaminando el alcance global de la misma manera que JavaScript. hace.

    Para solucionar estos problemas (o al menos mantenerlos a raya), debemos implementar soluciones alternativas, trucos e implementar un estilo de desarrollo que todo el equipo pueda seguir. Todo esto conduce a una calidad de resultados más baja y comprometida después de una migración gradual. También es más difícil mantener un proyecto de este tipo que después de una reescritura completa.

    Ambas opciones existentes tienen limitaciones y restricciones, pero aún tenemos que elegir una si es necesaria la migración . Sin embargo, ¿esta elección debería ser igual de dolorosa? ¿No sería fantástico combinar de alguna manera las mejores partes de ambos, minimizando al mismo tiempo los efectos secundarios negativos? ¿Es posible en absoluto?

     

    Permítanme presentarles la migración de Frankenstein.

    • Aproveche la sólida recuperación de datos y el tamaño de paquete optimizado con KendoReact Server Data Grid Probar ahora

    Migración Frankenstein. Parte 1: Teoría #

    Esta parte de la serie responde qué es la Migración Frankenstein. Vamos a descubrir en qué se diferencia de otros tipos de migración. Además, lo más importante, vamos a profundizar en la teoría de las tecnologías y enfoques que hacen que este tipo de migración sea incluso posible.

    ¿Por qué “Frankenstein”? #

    El nombre proviene de la forma en que funciona el enfoque. En esencia, proporciona una hoja de ruta para que dos o más aplicaciones, escritas en marcos completamente diferentes, funcionen como un cuerpo sólido y bien orquestado. Así como Victor Frankenstein construyó su monstruo en el libro de Mary Shelley “Frankenstein; o El Prometeo moderno” .

    La gente tiende a tener miedo de los monstruos. Típicamente. ( Vista previa grande )

    Tenga en cuenta que recientemente diferentes personas y organizaciones han explorado de forma independiente el problema de combinar diferentes marcos en el mismo proyecto: Micro Frontends , Allegro Tech , etc. Frankenstein Migration, sin embargo, es, en primer lugar, un enfoque independiente y estructurado de la migración .

    Hay dos tecnologías/enfoques fundamentales en el corazón de Frankenstein Migration:

    • Arquitectura de microservicios y
    • Componentes web

    Arquitectura de microservicios #

    La idea principal detrás de los microservicios ( al contrario de la arquitectura monolítica ) es que usted diseña su aplicación con la ayuda de servicios aislados e independientes dedicados a un pequeño trabajo en particular.

    Repetiré las cosas que debes tener en cuenta:

    • "independiente"
    • "un trabajo"

    La arquitectura de microservicios es un conjunto de servicios independientes que están todos conectados a una red. ( Vista previa grande )

    En una aplicación, dichos servicios se conectan a una red de comunicación que puede agregar, eliminar o reemplazar nuevos servicios fácilmente en cualquier momento, y eso es lo que llamamos "microservicios". Este enfoque flexible está bien establecido y ampliamente adoptado por los arquitectos de servidores y back-end. Sin embargo, ¿podemos tener microservicios reales en el frontend ? Chistes cortos

    Echemos un vistazo a las principales características del servicio en dicha arquitectura :

    • De tamaño pequeño,
    • Limitado por contextos,
    • Construido y lanzado con procesos automatizados,
    • Desarrollado de forma autónoma y
    • Desplegable de forma independiente.

    Los primeros tres puntos no son un problema para las tecnologías front-end. Prácticamente todos los marcos y bibliotecas modernos proporcionan uno u otro tipo de abstracción para satisfacer estos tres requisitos. Sin embargo, la independencia de los servicios tanto para el desarrollo como para la implementación siempre ha sido un problema para las tecnologías front-end. Incluso en el panorama de los marcos modernos que proporcionan un paradigma de un componente (como React o Vue), esos componentes generalmente siguen siendo muy dependientes del sistema y no pueden ser autónomos o independientes del marco que los inicializó. Por supuesto, siempre puedes recurrir a iframe, y obtener este nivel de independencia. Sin embargo, busquemos una alternativa mejor, no tan radical.

     

    Hay un tipo de componente que se acerca a este nivel de independencia y son los componentes web. Así que este es el segundo pilar de la Migración Frankenstein.

    Componentes web #

    La gente dice que hoy en día basta con mencionar “Componentes Web” para empezar una pelea. Personas como Rich Harris incluso escriben publicaciones en blogs sobre por qué no utilizan componentes web. Sin embargo, el propósito de este artículo no es convencerlo de que los componentes web son útiles ni iniciar un acalorado debate sobre el tema. Web Components no es una herramienta para hacer que todo esté bien . Como ocurre con cualquier otra herramienta, puede haber limitaciones y posibles efectos secundarios.

    Serhii Kulykov proporciona una serie de artículos mejor fundamentados sobre el tema y también organiza un repositorio de "Componentes web de la manera correcta" en el que puede encontrar mucha más información para el debate general sobre componentes web. Sin embargo, cuando se trata de la migración Frankenstein, los componentes web resultan ser un instrumento muy adecuado.

    Echemos un vistazo rápido a los elementos principales de los componentes web que los convierten en candidatos adecuados para cerrar las brechas en la adopción de microservicios por parte del frontend:

    • Elementos personalizados
    • DOM en la sombra

    En particular, Shadow DOM es la herramienta capaz de solucionar los problemas que normalmente encontramos en la migración gradual y proporciona un mecanismo de encapsulación real para el CSS del componente. Anteriormente, mencionamos que mantener una cascada de CSS es problemático cuando intentamos usar componentes escritos con diferentes marcos o bibliotecas uno al lado del otro en el ámbito global.

    Ahora veamos cómo Shadow DOM resuelve este problema.

    Alcance de CSS frente a encapsulación. El estilo Shadow DOM #

    El mecanismo de encapsulación de Shadow DOM es esencial para comprenderlo, ya que es diferente de cómo funcionan las herramientas populares como los módulos CSS o los atributos en Vue . Estas herramientas proporcionan alcance para los estilos, definidos en un componente, sin romper los estilos globales y otros componentes. Sin embargo, no protegen los componentes de estilos globales que se filtran al componente (el mismo problema de la cascada discutido anteriormente) y, por lo tanto, potencialmente rompen sus componentes.scoped

    Al mismo tiempo, los estilos definidos dentro de Shadow DOM no solo tienen como alcance el componente actual, sino que también están protegidos de estilos globales que no tienen acceso explícito a las partes internas de Shadow DOM sin importar la especificidad. Para verlo en acción, eche un vistazo al ejemplo actualizado :

     

    Aquí, sacamos estilos del componente Vue, directamente al Shadow DOM y eso es lo que sucede (aunque automáticamente) cuando configuras tus componentes Vue para que funcionen dentro de Shadow DOM . Este ejemplo muestra que Shadow DOM proporciona un mecanismo para componentes genuinamente independientes que se pueden usar en cualquier contexto (biblioteca, marco) preservando al mismo tiempo la apariencia y la funcionalidad de estos componentes.

    Ahora hablemos de los conceptos y pasos principales de Frankenstein Migration para ver cómo exactamente los microservicios y los componentes web nos ayudan en la migración de aplicaciones front-end.

    Supongamos que tiene un proyecto que desea migrar a otro marco.

    Nuestro proyecto de demostración en un marco que ya no es tan popular y que queremos migrar. ( Vista previa grande )

    No importa de qué marco/biblioteca migremos y a qué marco/biblioteca queramos llegar; El principio y los pasos son los mismos para más o menos cualquier herramienta que elija (algunas excepciones genéricas se mencionan más adelante en el artículo). Es por eso que a Frankenstein Migration se le llama el enfoque “agnóstico del marco”.

    Ahora bien, ¿por dónde empezamos?

    1. Identificar microservicios
    2. Permitir el acceso de host a alienígena
    3. Escribir un componente alienígena
    4. Escribir un contenedor de componentes web alrededor del servicio Alien
    5. Reemplazar el servicio de host con un componente web
    6. Enjuague y repita
    7. Cambiar a extraterrestre

    1. Identificar microservicios #

    Es el paso central, esencial para el éxito o el fracaso de todo el proceso. Así que deberíamos profundizar más aquí.

    Técnicamente, tenemos que dividir nuestra aplicación existente en microservicios virtualmente . Sin embargo, es un proceso completamente subjetivo y no tiene una respuesta "correcta". Sin embargo, ¿qué significa entonces en la práctica?

    Por “virtualmente” quiero decir que, en general, no es necesario cambiar físicamente la aplicación existente: basta con tener la estructura establecida en cualquier forma, aunque sólo sea en papel.

    Tenemos que tener una división clara en nuestra aplicación actual en servicios que sean:

    • Independiente;
    • Dedicado a un pequeño trabajo.

    Un campo de entrada para agregar nuevos elementos a una base de datos podría ser un ejemplo de un servicio: está dedicado a un trabajo en particular (agregar nuevos elementos) y realiza el trabajo sin depender de ningún otro servicio. Alternativamente, la lista completa de elementos ya agregados a la base de datos: tiene una funcionalidad trivial y, nuevamente, no depende de otros componentes para enumerar elementos . Creo que no suena demasiado complicado, pero podría ser una sensación engañosa.

    Comencemos con las partes fáciles: si un marco en su proyecto actual se basa en un concepto de "componente" (React, Vue), probablemente ya tenga una base razonable para este tipo de migración. Puede tratar cada componente de su aplicación como un servicio independiente en una arquitectura de microservicios.

     

    Si su proyecto actualmente es heredado (por ejemplo, como jQuery), debe encender su imaginación y pensar cómo le gustaría estructurar su aplicación, siguiendo los principios de independencia de los microservicios y un trabajo por servicio.

    Podemos estructurar nuestra aplicación de la forma que queramos siempre que sigamos los principios de los microservicios. ( Vista previa grande )

    Refactorizar si es necesario #

    Odio mi capacidad de repetir cosas varias veces, pero en este caso tiene mucho sentido: asegúrese de que sus servicios (o componentes, o contenedores, o como prefiera llamar a sus bloques de construcción) no dependan de otros servicios. De lo contrario, ambos servicios deberían ser tratados como uno solo, en aras de la independencia y el aislamiento.

    Una prueba sencilla para asegurarse de que su servicio sea adecuadamente independiente : elimine el HTML de su componente/servicio del Host y vuelva a cargar la aplicación. Si no hay errores de JS en la consola y el resto de la aplicación funciona como se esperaba, lo más probable es que el servicio en cuestión sea lo suficientemente independiente del resto de la aplicación.

    Para darle una mejor explicación, consideremos el siguiente ejemplo heredado, artificialmente simplificado :

    índice.html

    form id="form" input id="inputTodo" type="text" placeholder="New Todo"/ button type="submit"Add Todo/button/formul id="listing" class="d-none"/ul

    index.js

    const form = document.getElementById("form");form.addEventListener("submit", ev = { ev.preventDefault(); const listing = document.getElementById("listing"); const input = document.getElementById("inputTodo"); const newEntry = document.createElement("li"); newEntry.innerHTML = input.value; input.value = ""; listing.prepend(newEntry); listing.classList.remove("d-none");});

    Aquí, #formespera #listingestar presente en el marcado ya que su submitcontrolador actualiza el listado directamente. Por lo tanto, estos dos dependen uno del otro y no podemos dividirlos en servicios separados: son partes del mismo trabajo y se ayudan mutuamente para cumplir el mismo propósito.

    Sin embargo, como alternativa posiblemente mejor, podríamos refactorizar este código para independizar los dos componentes entre sí y satisfacer el requisito de independencia:

    index.js

    function notifyAboutNewItem(ev) { ev.preventDefault(); const input = document.getElementById("inputTodo"); const event = new CustomEvent("new-todo", { detail: { val: input.value } }); document.dispatchEvent(event); input.value = "";}function updateList(ev) { const listing = document.getElementById("listing"); const newEntry = document.createElement("li"); newEntry.innerHTML = ev.detail.val; listing.prepend(newEntry); listing.classList.remove("d-none");}document.getElementById("form").addEventListener("submit", notifyAboutNewItem);document.addEventListener("new-todo", updateList);

    Ahora, nuestros componentes #formy #listingno se comunican entre sí directamente, sino a través del evento DOM (puede ser una gestión de estado o cualquier otro mecanismo de almacenamiento con notificación): cuando se agrega un nuevo elemento, notifyAboutNewItem()envía un evento, mientras nos suscribimos #listinga Escuche este evento. Ahora cualquier componente puede enviar este evento. Además, cualquier componente puede escucharlo: nuestros componentes se volvieron independientes entre sí y, por lo tanto, podemos tratarlos por separado en nuestra migración.

     

    ¿Demasiado pequeño para un servicio? #

    Otra cosa a tener en cuenta: al dividir su aplicación con componentes ya existentes (como React o Vue) en servicios, algunos de sus componentes pueden ser demasiado pequeños para un servicio adecuado. No quiere decir que no puedan ser pequeños, porque nada le impide estructurar su aplicación tan atómica como desee, pero la mayoría de los componentes simples y reutilizables de la interfaz de usuario (como el botón de formulario o el campo de entrada en el ejemplo anterior) se incluyen mejor en servicios más amplios con el fin de minimizar el trabajo para usted.

    A mayor escala, puedes abordar el Paso 1 tan caótico como desees. No es necesario que inicies Frankenstein Migration con el plan global: puedes comenzar con solo un elemento de tu aplicación . Por ejemplo, divida algunos complejos sectionen servicios. Alternativamente, puede estructurar su aplicación en una ruta o página completa a la vez y luego, tal vez, se sectionconvierta en un solo servicio. No importa mucho; cualquier estructura es mejor que una aplicación monolítica pesada y difícil de mantener. Sin embargo, sugeriría tener cuidado con el enfoque demasiado detallado: es aburrido y no proporciona muchos beneficios en este caso.

    Mi regla general: se obtiene el mejor flujo de proceso con servicios que se pueden migrar y poner en producción en una semana. Si se necesita menos, entonces sus servicios son demasiado pequeños. Si tarda más, es posible que esté intentando masticar demasiados trozos grandes, por lo que es mejor dividirlos. Sin embargo, todo depende de tu capacidad y de las necesidades de tu proyecto.

    Después de dividir virtualmente su aplicación actual en servicios, estamos listos para pasar al siguiente paso.

    2. Permitir el acceso de host a alienígena #

    Por supuesto, este título debería ser absolutamente confuso. Tampoco hemos discutido qué es Host ni hemos mencionado a Alien todavía. Así que aclaremos esto primero.

    Hemos mencionado que los servicios en nuestra aplicación actual deben ser independientes. Sin embargo, este no es el único lugar donde luchamos por la independencia. Al contrario del enfoque típico de migración gradual, donde ponemos todo en el mismo recipiente y desarrollamos nuevos componentes junto con los antiguos, Frankenstein Migration requiere que desarrollemos nuevos componentes fuera de la aplicación actual.

    Tengan paciencia conmigo.

    Además, en el artículo, usaremos la palabra Host para referirnos a la aplicación actual, escrita con el marco del que estamos a punto de migrar . Al mismo tiempo, la nueva aplicación, escrita con el marco al que estamos migrando se llamará Alien , ya que inyecta sus servicios en Host en algún momento.

    'Host' es nuestra aplicación actual, mientras que 'Alien' es nuestra aplicación migrada en el nuevo marco. ( Vista previa grande )

    Sí, no tratamos a Alien simplemente como un conjunto de componentes, sino como una aplicación adecuada que construimos con el tiempo. Técnicamente, tanto Host como Alien deberían ser dos aplicaciones completamente diferentes escritas con cualquier marco que desee, con dependencias propias, herramientas agrupadas, etc. Es esencial evitar los problemas típicos de la migración gradual; sin embargo, este enfoque tiene un beneficio adicional significativo. Al mantener Host y Alien independientes, podemos implementar ambos sistemas en cualquier momento , en caso de que lo necesitemos en algún momento de la migración.

    Hay varias formas de organizar Host y Alien:

    • Diferentes dominios o direcciones IP;
    • Diferentes carpetas en su servidor;
    • submódulos de git ;
    • Etcétera.

    Sin embargo, la condición principal para cualquier escenario que elijas es que el Anfitrión tenga acceso a los activos de Alien. Por lo tanto, si elige trabajar con diferentes dominios, debe considerar la configuración de CORS para su dominio Alien. Si decide organizarlo de manera tan simple como diferentes carpetas en su servidor, asegúrese de que los recursos de la carpeta del Host tengan acceso a la carpeta de Alien. Si decide git submodule,antes de agregar Alien como submódulo de su Host, asegúrese de leer la documentación y saber cómo funciona: no es tan difícil como puede parecer.

    El anfitrión debe tener acceso a Alien. ( Vista previa grande )

    Una vez que haya configurado sus aplicaciones y haya proporcionado acceso desde






    Tal vez te puede interesar:

    1. ¿Deberían abrirse los enlaces en ventanas nuevas?
    2. 24 excelentes tutoriales de AJAX
    3. 70 técnicas nuevas y útiles de AJAX y JavaScript
    4. Más de 45 excelentes recursos y repositorios de fragmentos de código

    Migración Frankenstein: enfoque independiente del marco (Parte 1)

    Migración Frankenstein: enfoque independiente del marco (Parte 1)

    Anuncie en la revista Smashing Patrones de diseño de interfaces inteligentes, vídeo de 10h + formación UX Índice

    programar

    es

    https://aprendeprogramando.es/static/images/programar-migracion-frankenstein-enfoque-independiente-del-marco-parte-1-1001-0.jpg

    2024-05-21

     

    Migración Frankenstein: enfoque independiente del marco (Parte 1)
    Migración Frankenstein: enfoque independiente del marco (Parte 1)

    Si crees que alguno de los contenidos (texto, imagenes o multimedia) en esta página infringe tus derechos relativos a propiedad intelectual, marcas registradas o cualquier otro de tus derechos, por favor ponte en contacto con nosotros en el mail [email protected] y retiraremos este contenido inmediatamente

     

     

    Top 20