Temas dessa edição
GraphQL está vivendo seu momento. Encorajamos os times a usar GraphQL e as ferramentas emergentes ao seu redor, mas também a adotar cautela no uso de tecnologias de foco específico para resolver problemas demais.
Originalmente projetado para navegação e interação com documentos, o navegador web hoje essencialmente hospeda aplicações. A incompatibilidade continua sendo um desafio para as pessoas desenvolvedoras, que continuam refletindo sobre a melhor forma de construir aplicações web.
Diversos tipos de ferramentas inovadoras de visualização têm surgido, para inúmeras finalidades, incluindo infraestrutura, ciência de dados e recursos de nuvem. À medida que os ecossistemas de desenvolvimento se tornam mais complexos, uma imagem geralmente ajuda muito a gerenciar a inevitável sobrecarga cognitiva.
A infraestrutura como código chegou à adolescência. As ferramentas evoluíram substancialmente em relação à primeira geração. Mas, como acontece com adolescentes em geral, essa fase tem seus pontos positivos e negativos.
Várias de nossas discussões giram em torno de ferramentas e técnicas que promovem a democratização da programação: habilitar as pessoas que não programam a realizar tarefas que até então apenas as pessoas programadoras conseguiam. Mas, como acontece com muitas ferramentas de baixo código, os desdobramentos positivos e negativos tradicionais permanecem.
A imponência do GraphQL
Vemos um aumento na adoção do GraphQL em muitos times, acompanhado por um ecossistema de suporte também em crescimento. Ele resolve alguns problemas comuns que se manifestam em arquiteturas distribuídas modernas, como microsserviços: quando as pessoas desenvolvedoras dividem as coisas em pequenos pedaços, elas devem reagregar informações com frequência para resolver os requisitos de negócio. O GraphQL oferece recursos convenientes para resolver esse problema cada vez mais comum. Como todas as abstrações poderosas, ele oferece compensações e requer consideração cuidadosa por parte dos times para evitar efeitos negativos no longo prazo. Por exemplo, vemos times fornecendo muitas informações sobre os detalhes de implementação subjacentes por meio de uma ferramenta de agregação, levando a uma fragilidade desnecessária na arquitetura. Outro benefício de curto prazo que pode se transformar em dor de cabeça a longo prazo surge quando os times tentam usar uma ferramenta de agregação para criar um modelo de dados canônico, universal e centralizado. Encorajamos os times a usar GraphQL e as ferramentas emergentes ao seu redor, mas tendo cautela com as tecnologias de foco específico que são generalizadas para resolver muitos problemas.
A luta com o navegador continua
O navegador web foi originalmente projetado para navegação e interação com documentos, mas hoje ele essencialmente hospeda aplicações, e a incompatibilidade de abstrações continua desafiando as pessoas desenvolvedoras. Para superar as muitas dores de cabeça inerentes a essa incompatibilidade, os times de desenvolvimento continuam repensando e desafiando as abordagens estabelecidas para testes de navegador, gerenciamento de estado e construção de aplicações ricas e rápidas para navegadores de forma geral. Vemos várias dessas tendências no Radar. Em primeiro lugar, desde que movemos o Redux para o anel Adote em 2017, como forma padrão de gerenciar o estado em aplicações React, vemos agora pessoas desenvolvedoras procurando em outros lugares (Recoil), ou adiando a decisão por uma biblioteca de gerenciamento de estado. Em segundo lugar, Svelte vem conquistando mais interesse e desafiando um dos conceitos estabelecidos e aplicados por frameworks de aplicações populares como React e Vue.js: o virtual DOM. Em terceiro lugar, continuamos vendo novas ferramentas para lidar com testes no navegador: Playwright é mais uma tentativa de melhorar os testes de UI, e Mock Service Worker é uma nova abordagem para desacoplar testes de suas interações back-end. Em quarto lugar, continuamos observando o desafio de equilibrar a produtividade de pessoas desenvolvedoras com desempenho, com os polyfills adaptados ao navegador buscando mover a escala nessa balança.
Visualize tudo
Este volume do Radar traz diversos blips sobre variadas áreas da tecnologia, mas com uma coisa em comum: visualização. Você encontrará blips sobre infraestrutura, ciência de dados, recursos de nuvem e uma série de outras ferramentas de visualização inovadoras, incluindo algumas formas muito eficazes de visualizar abstrações difíceis. Você também encontrará discussões sobre ferramentas de visualização de dados interativas e ferramentas de painel, como Dash, Bokeh e Streamlit, bem como uma série de ferramentas de visualização de infraestrutura, incluindo Kiali para visualização de malhas de serviço em arquiteturas de microsserviços. À medida que os ecossistemas de desenvolvimento se tornam mais complexos, uma imagem geralmente ajuda muito a gerenciar a inevitável sobrecarga cognitiva.
A adolescência da infraestrutura como código
Gerenciar infraestrutura como código tornou-se mais comum à medida que as organizações enxergam os benefícios de automatizar a infraestrutura. Consequentemente, cria-se um ciclo de feedback de adoção e inovação para quem cria ferramentas e frameworks. Ferramentas como CDK e Pulumi, entre outras, oferecem recursos que vão muito além da primeira geração, evoluindo de tal forma que acreditamos que a infraestrutura como código chegou à adolescência — com todas as suas conotações positivas e negativas. Foi uma surpresa agradável o número de blips, em todos os quadrantes, refletindo positivamente o aumento da maturidade do ecossistema. No entanto, também discutimos os desafios em torno da falta de padrões maduros e as dificuldades que muitas empresas enfrentam ao tentar encontrar o melhor uso desse recurso — o que indica crescimento contínuo em direção à maturidade. Temos esperança de que a comunidade de infraestrutura continuará aprendendo lições de design de software, especialmente em termos de criação de uma infraestrutura implantável com fraco acoplamento.
Democratizando a programação
Várias de nossas discussões giram em torno de ferramentas e técnicas que promovem a democratização da programação: ou seja, habilitar as pessoas que não programam a realizar tarefas que até então apenas as pessoas programadoras poderiam fazer. Soluções como IFTTT e Zapier, por exemplo, são populares neste espaço há bastante tempo. Temos observado um uso crescente de ferramentas como Amazon Honeycode, um ambiente de baixo código para a criação de aplicações de negócio simples. Embora ferramentas como essas forneçam ambientes de programação adequados à finalidade, os desafios surgem ao movê-los para ambientes de produção em escala. Pessoas desenvolvedoras e especialistas em planilhas há muito tempo conseguem encontrar um meio-termo entre ambientes de programação específicos de domínio e tradicionais. O advento de ferramentas mais modernas renova essa discussão em domínios mais amplos, com muitos dos mesmos desdobramentos positivos e negativos.
Contribuições
O Technology Radar é preparado pelo Conselho Consultivo de Tecnologia da ThoughtWorks, composto 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|