Temas para esta edición

La grandiosidad de GraphQL
Vemos que ha aumentado la adopción de GraphQL en muchos equipos, además de la existencia de un próspero ecosistema de soporte. GraphQL resuelve algunos problemas comunes que se manifiestan en las arquitecturas distribuidas modernas como los microservicios. Cuando se dividen las cosas en partes pequeñas, a menudo es necesario volver a consolidar la información para resolver los requerimientos del negocio. Esta herramienta ofrece capacidades convenientes que ayudan a resolver este problema cada vez más común. Como todas las abstracciones poderosas, puede ser necesario realizar compromisos y efectuar evaluaciones cuidadosas por parte de los equipos para evitar efectos negativos a largo plazo. Por ejemplo, hemos visto casos donde se provee demasiados detalles de implementación subyacentes a través de una herramienta de agregación, lo que genera una fragilidad innecesaria en la arquitectura. También vimos que facilidades de corto plazo se convirtieron en dolores de cabeza en el largo plazo, como cuando los equipos intentaron utilizar una herramienta de agregación para crear un modelo de datos canónico, universal y centralizado. Alentamos a que los equipos utilicen GraphQL y las herramientas emergentes que lo rodean, pero insistimos en que sean cautelosos en no generalizar tecnologías cuyo enfoque es restringido para resolver demasiados problemas.

Los desafíos con el Navegador continúan
El navegador web fue diseñado originalmente para explorar documentos, y hoy en día permite principalmente la ejecución de aplicaciones, con lo que el desfase en la abstracción continúa siendo un reto para las personas desarrolladoras. Para superar los múltiples problemas inherentes a este desfase, los equipos de desarrollo siguen repensando y volviendo a desafiar a los métodos establecidos para ejecutar pruebas en el navegador, gestionar el estado y, en general, construir aplicaciones ricas y rápidas. Hemos visto varias de estas tendencias en el Radar. Primero, movimos a Redux a “Adoptar” en 2017 y lo presentamos como la solución por defecto para gestionar el estado en aplicaciones React, y ahora vemos que los equipos de desarrollo buscan algo distinto (Recoil) o retrasan la decisión de adoptar una librería de gestión del estado. Segundo, Svelte ha estado ganando más interés y desafía uno de los conceptos establecidos y aplicados por los frameworks populares como React y Vue.js: el DOM virtual. Tercero, seguimos viendo nuevas herramientas para ejecutar pruebas en el navegador: Playwright es otro nuevo intento de mejorar las pruebas de interfaz de usuario mientras que Mock Service Worker es un nuevo método para desacoplar las pruebas de las interacciones con el back-end. Cuarto, continuamos observando el reto de balancear la productividad de las personas desarrolladoras con el rendimiento: con los polyfills adaptados al navegador se intenta cambiar la escala en este compromiso.

Visualizar todo
Esta edición del Radar presenta varios blips a través de todo el escenario tecnológico con una cosa en común: visualización. Encontrarás blips sobre infraestructura, ciencia de datos, recursos en la nube y un conjunto de innovadoras herramientas de visualización, incluyendo varias formas efectivas para ver abstracciones complicadas. También encontrarás discusiones sobre herramientas interactivas para la visualización de datos y tableros como Dash, Bokeh y Streamlit, así como tambien herramientas para la visualización de la infraestructura, como Kiali, utilizada para visualizar mallas de servicio en arquitecturas de microservicios. A medida que los ecosistemas de desarrollo se hacen más complejos una imagen generalmente ayuda a dominar la inevitable sobrecarga cognitiva.

Adolescencia de la Infraestructura como Código
Administrar la infraestructura como código se ha hecho más común a medida que las organizaciones ven los beneficios de automatizar su infraestructura creando, por consiguiente, un ciclo de retroalimentación de innovación-adopción para los creadores de herramientas y frameworks. Herramientas como el CDK de AWS y Pulumi, entre otras, ofrecen capacidades más extensas que sus predecesoras, mejorando a tal punto que creemos que la práctica de la infraestructura como código ha llegado a su adolescencia, con sus consecuencias tanto positivas como negativas. Estamos gratamente sorprendidos del número de blips en todos los cuadrantes que reflejan positivamente la mejora en madurez de este ecosistema. Sin embargo, también discutimos los desafíos en cuanto a la falta de patrones maduros y los problemas que muchas compañías enfrentan cuando tratan de encontrar el mejor uso de esta práctica, todos los cuales evidencian el avance en el camino hacia la madurez. Esperamos que la comunidad de infraestructura siga aprendiendo lecciones del diseño de software, especialmente en términos de la creación de una infraestructura poco acoplada que sea capaz de ser desplegada.

Democratizando la programación
Varias de nuestras discusiones giran en torno a las herramientas y técnicas que promueven la democratización de la programación: habilitar a cualquier persona para ejecutar tareas que anteriormente solo las personas con conocimientos de programación podían realizar. Por ejemplo, soluciones como IFTTT y Zapier han sido muy populares en este espacio por mucho tiempo. Hemos observado un incremento en el uso de herramientas como Amazon Honeycode, una herramienta que permite crear aplicaciones de negocio simples sin saber programar. A pesar de que estas herramientas proveen un ambiente de programación de propósito específico, los desafíos surgen cuando se mueven estas soluciones a ambientes de producción de gran escala. Las personas desarrolladoras y las expertas con las hojas de cálculo, por mucho tiempo han buscado la forma de encontrar un punto medio entre los ambientes de programación específicos a un dominio y los tradicionales. El advenimiento de nuevas y modernas herramientas renueva la discusión a través de dominios más amplios, donde se presentan muchos de los mismos pros y contras.
Contribuyentes
El Technology Radar está preparado por la Junta Asesora de Tecnología de ThoughtWorks, compuesta por:
Rebecca Parsons (CTO)| Martin Fowler (Chief Scientist)| Bharani Subramaniam| Birgitta Böckeler| Brandon Byars| Camilla Falconi Crispim| Cassie Shum| Erik Doernenburg| Evan Bottcher| Fausto de la Torre| Hao Xu| Ian Cartwright| James Lewis| Lakshminarasimhan Sudarshan| Mike Mason| Neal Ford| Ni Wang| Perla Villarreal| Rachel Laycock| Scott Shaw| Shangqi Liu| Zhamak Dehghani|