Resultados da busca

Introducción En el mundo digital actual, las API (interfaces de programación de aplicaciones) se han convertido en los componentes básicos de las aplicaciones modernas, impulsando la transformación digital al conectar diferentes sistemas, plataformas y aplicaciones. A medida que aumenta la cantidad de API, también lo hace la complejidad de mantenerlas. La documentación y el seguimiento de las API pueden convertirse en una tarea abrumadora, más aún cuando estas API se actualizan con frecuencia. Aquí es donde entran en juego OpenAPI y herramientas como Optic. ¿Qué es OpenAPI? OpenAPI es una especificación para crear API que ofrece grandes beneficios. Permite a los desarrolladores y arquitectos de software diseñar, crear, documentar y administrar las API, proporcionando una interfaz estándar e independiente del idioma para las API RESTful. OpenAPI ayuda a acelerar el desarrollo, mejorar la calidad de las API y mejorar la usabilidad y la adopción de las API. Sin embargo, crear y mantener un documento de OpenAPI puede ser una tarea que requiere mucho tiempo y es propensa a errores, especialmente cuando tiene que actualizarlo manualmente cada vez que cambia su API. Beneficios del uso del Optic Ahorra tiempo: con Optic, ya no tiene que actualizar manualmente las especificaciones de su API. Sincroniza automáticamente su API y su documentación, ahorrándole un valioso tiempo de desarrollo. Mejora la precisión: al monitorear el tráfico de su API, Optic reduce las posibilidades de error humano que vienen con las actualizaciones manuales, asegurando que la documentación de su API sea siempre precisa. Facilita la colaboración: Optic facilita la colaboración en el desarrollo de API. Con la generación automática de especificaciones API actualizadas, los miembros del equipo pueden comprender fácilmente el estado actual de la API y colaborar de manera más eficaz. Mejora la experiencia del desarrollador: con una especificación OpenAPI actualizada y precisa, los desarrolladores pueden comprender rápidamente cómo usar su API, lo que mejora su experiencia general. Configuración de la Optic Antes de profundizar, deberá instalar Optic. Asegúrese de tener instalado Node.js en su sistema, ya que Optic lo requiere. Puede instalar Optic globalmente usando el administrador de paquetes npm de la siguiente manera: npm install -g @useoptic/cli Iniciando la Optic en su proyecto Una vez instalado, debe inicializar Optic en su proyecto API. Navegue al directorio de su proyecto y ejecute: api init Esto configurará Optic en su proyecto, creando un archivo de configuración optic.yml donde puede definir la configuración y las tareas de su API. Configuración de su tarea API En el archivo optic.yml, defina las tareas para su API. Una tarea representa un determinado estado de su API, como ejecutar sus pruebas o ejecutar su API en desarrollo. Este es un ejemplo de cómo configurar una tarea para una API de Node.js que se ejecuta en localhost y el puerto 3000: tasks:my_api:command: npm startinboundUrl: http://localhost:3000 En este ejemplo, my_api es el nombre de la tarea, command es el comando para iniciar su API e inboundUrl es la URL donde se ejecuta su API. Iniciar Optic con su API Para iniciar su API con Optic, puede usar el comando api start seguido del nombre de su tarea: api start my_api Ahora, Optic está observando el tráfico de su API, observando cualquier cambio en el comportamiento de la API. Hacer cambios y revisarlos con Optic Supongamos que agregó un nuevo punto final o modificó uno existente. Cuando utilice su API o ejecute sus pruebas, Optic observará estos cambios y sugerirá actualizaciones para la especificación de su API. Para ver estos cambios, puede abrir el panel óptico de su navegador, normalmente en http://localhost:34444. En el panel, verá una lista de puntos finales. Optic marcará cualquier cambio observado en el comportamiento de su API, lo que le permitirá revisarlos, documentarlos y aprobarlos. Una vez que esté satisfecho con los cambios, haga clic en el botón "Aprobar" y Optic actualizará su especificación OpenAPI. Conclusión En un panorama digital que cambia rápidamente, tener una herramienta como Optic para automatizar la tediosa tarea de mantener las especificaciones de su API es invaluable. Mejora la eficiencia y garantiza que la documentación de su API sea precisa y esté actualizada, lo que mejora la colaboración y mejora la experiencia general del desarrollador. Entonces, ya sea que sea un veterano de API o que recién esté comenzando con el desarrollo de API, Optic es una herramienta que vale la pena explorar. Para obtener más información, consulte: https://www.useoptic.com

¿Cuál es su estrategia para migrar aplicaciones en su organización? En varios clientes a los que atendemos, existen escenarios en los que nos enfrentamos a numerosos componentes heredados en las organizaciones. Muchos de estos son cruciales y fundamentales para la operación del negocio, sin embargo, existen los desafíos de modernizarlos de la manera más adherente a las exigencias de todas las industrias del mercado. Patrón de estrangulamiento de la aplicación El patrón Throttle se ha vuelto muy popular y se ha documentado en el sitio web microservices.io ( https://microservices.io/patterns/refactoring/strangler- application.html), el objetivo de este patrón es hacer que las aplicaciones heredadas cambien gradualmente, cambiando los servicios de manera que los consumidores y los canales se vean afectados lo menos posible. Tipos de Componentes Legacy más encontrados por nuestro equipo de Consultoría Procedimientos almacenados y componentes de bases de datos Hace más de 20 años, era muy común construir aplicaciones en el modelo cliente-servidor (Cliente-Servidor), que se podía dividir en dos formas: Thin Client/Fat Server y Fat Client/Thin Server. Debido a la capacidad computacional mucho mayor en el lado del servidor, el modelo Fat Server fue mucho más utilizado, lo que resultó en la creación de aplicaciones de escritorio utilizando Delphi, Visual Basic, Fox pro, Oracle Forms, accediendo a bases de datos como numerosas funciones (procedimientos almacenados) , debido al gran poder de las bases de datos en la época, por ejemplo, Oracle, que cuenta con PL/SQL, que tiene una capacidad increíble no solo para concentrar reglas de negocio sino varias funciones que facilitaban la construcción de aplicaciones sumamente robustas. Usemos aquí un ejemplo de una arquitectura hecha para un cliente con una combinación de Delphi y Oracle: Muchos clientes tienen numerosas reglas comerciales, incluso integraciones creadas con PL/SQL. Con el tema del soporte de Windows, muchas de estas aplicaciones por ejemplo Delphi, pero incluso otras tecnologías de los años 90/2000 pueden tener problemas para seguir funcionando, por eso, algunas de estas empresas están literalmente desesperadas y la razón es "¿Cómo puedo migrar esta solución a otro sistema, teniendo en cuenta que todas mis reglas no se pueden portar? ¿Cuál fue nuestra propuesta? Adquirir un nuevo ERP sería complejo, ya que aún existiría el problema de migrar las reglas comerciales. Entonces, ¿qué sugerimos? 1- Una nueva aplicación de una sola página de front-end con Angular, que traslada la experiencia del usuario de escritorio y agrega todas las mejoras modernas. 2- Esta nueva aplicación SPA accedería a las API REST, que actúan como fachadas para acceder a todas las funcionalidades y reglas que aún se encuentran en la base de datos de Oracle. 3: la atención se centró en las funcionalidades críticas y, con eso, los nuevos usuarios comenzaron a usar esta nueva interfaz, que interactuaba con los mismos datos que la aplicación anterior de Delphi. 4- Gradualmente, todas las funciones se trasladaron al SPA, haciéndolas 100% compatibles con las funciones de la aplicación de escritorio Delphi. 5- Con los usuarios migrados a esta nueva interfaz de usuario en la aplicación SPA, la aplicación de escritorio ya no se usa. 6- Con el uso de APIs, toda funcionalidad escrita en PL/SQL podría dar lugar a un nuevo microservicio utilizando tecnologías como docker, kubernetes, protocolos como WebSockets, etc. 7- La nueva arquitectura, además de los microservicios, ahora tiene 3 bases de datos, algunas cosas todavía en Oracle, pero también coexistiendo con MongoDB y Redis. Beneficios para el Cliente y el Negocio Ahorro: El cliente no necesitaba invertir en un nuevo ERP, lo que supondría una inversión importante. Reducción del riesgo de migración y personalización: Personalizar un ERP trayendo las reglas existentes es una de las tareas más riesgosas y también más costosas para las modernizaciones en este sentido. Mejora de la experiencia: Los usuarios han conservado la funcionalidad del escritorio, con la riqueza de una aplicación de una sola página, con todas las mejoras aplicadas por las disciplinas de UX ( experiencia de usuario). Servicio para nuevos canales comerciales: para el acceso de terceros o socios, estos pueden integrarse a través de API que ahora actúan como una capa de entrada central para todos los servicios. Conclusión Este es un ejemplo del trabajo que realizamos para varios clientes, atendiendo a la particularidad de cada uno de ellos, aplicando una metodología que llamamos RNC(https://www.skalena.com/modernizacao-legados-skalena), próximamente publicaremos la Parte II de este artículo, donde hablaremos sobre estrategias para modernizar WebServices/SOAP y en la Parte III, sobre el concepto de Lift & Shift. ¿Quieres charlar, tomar un café o incluso una sesión de conversación de 30 minutos sobre estos y otros temas? Envíanos un mensaje: https://www.skalena.com/contacto