Themes for this edition
GraphQL is having a moment. We encourage teams to use GraphQL and the burgeoning tools around it but also to exercise caution when using narrowly focused technology to solve too many problems.
Originally designed for document browsing, the web browser today primarily hosts applications. That impedance mismatch remains a challenge to developers, who keep rethinking how to best build web applications.
All kinds of innovative visualization tools have emerged for myriad purposes, including infrastructure, data science and cloud resources. As developer ecosystems become more complex, a picture often goes a long way toward taming the inevitable cognitive overload.
Infrastructure as code has hit adolescence. Tooling has improved substantially over its first-generation. But as with most teenagers, it has its positives and negatives.
Several of our discussions revolve around tools and techniques that promote the democratization of programming: allowing nonprogrammers the ability to perform tasks that previously only programmers could. But as with many low-code tools, the traditional positive and negative trade-offs remain.
GraphQL Grandiosity
We see a swell in adoption of GraphQL on many teams, along with a thriving support ecosystem. It solves some common problems that are manifest in modern distributed architectures such as microservices: when developers break things into small pieces, they must often re-aggregate information to solve business requirements. GraphQL offers convenient capabilities to solve this increasingly common problem. Like all powerful abstractions, it offers trade-offs and requires careful consideration by teams to avoid long-term negative effects. For example, we've seen teams provide too much detail about the underlying implementation details via an aggregation tool, leading to unnecessary brittleness in architecture. Another short-term convenience turned long-term headache comes when teams try to use an aggregation tool to create a canonical, universal, centralized data model. We encourage teams to use GraphQL and the burgeoning tools around it; but be cautious of narrowly focused technology generalized to solve too many problems.
The Struggle with the Browser Continues
The web browser was originally designed for document browsing, but now it primarily hosts applications, and the abstraction mismatch continues to challenge developers. To overcome the many headaches inherent in this mismatch, developers keep rethinking and rechallenging established approaches for browser testing, state management and building fast and rich browser applications in general. We see several of these trends in the Radar. First, since we moved Redux to Adopt in 2017 as the default way to manage state in React applications, we now see developers either look elsewhere (Recoil) or delay the decision for a state management library. Second, Svelte has been gaining more interest, and it is challenging one of the established concepts applied by popular application frameworks such as React and Vue.js: the virtual DOM. Third, we keep seeing new tools to deal with testing in the browser: Playwright is yet another attempt at improving UI testing, and Mock Service Worker is a novel approach to decouple tests from their back-end interactions. Fourth, we continue to see the challenge of balancing developer productivity with performance, with browser-tailored polyfills aiming to move the scale in that trade-off.
Visualize All the Things
This Radar features several blips across the technology landscape with one thing in common: visualization. You’ll find blips on infrastructure, data science, cloud resources and a host of other innovative visualization tools, including some very effective ways to view difficult abstractions. You'll also find discussions of interactive data tools visualization and dashboarding tools, such as Dash, Bokeh and Streamlit, as well as a host of infrastructure visualization tools, including Kiali for service mesh visualization in microservices architectures. As developer ecosystems become more complex, a picture often goes a long way toward taming the inevitable cognitive overload.
Adolescence of Infrastructure as Code
Managing infrastructure as code has become more common as organizations see the benefits of automating infrastructure, consequently creating an innovation-adoption feedback loop for the creators of tools and frameworks. Tools such as CDK and Pulumi among others offer capabilities far beyond the first generation, improving so much that we believe infrastructure as code has reached its adolescence, with both positive and negative connotations. We were pleasantly surprised at the number of blips in all quadrants reflecting positively on the increasing maturity of the ecosystem. However, we also discussed the challenges around the lack of mature patterns and the struggles many companies face as they're trying to find the best use of this capability — all of which are indicators of continuing growth toward maturity. We're hopeful that the infrastructure community will continue to learn lessons from software design, especially in terms of creating a loosely coupled deployable infrastructure.
Democratizing Programming
Several of our discussions revolve around tools and techniques that promote the democratization of programming: allowing nonprogrammers the ability to perform tasks that previously only programmers could do. For example, solutions such as IFTTT and Zapier have for long been popular in this space. We’ve observed an increasing use of tools such as Amazon Honeycode, a low-code environment for creating simple business applications. Although tools such as these provide fit-to-purpose programming environments, challenges arise when moving them to production-scale environments. Developers and spreadsheet wizards have long managed to find a compromise between domain-specific and traditional coding environments. The advent of more modern tools renews that discussion across wider domains, with many of the same positive and negative trade-offs.
Contributors
The Technology Radar is prepared by the ThoughtWorks Technology Advisory Board, comprised of:
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|