From 8779dd66824514d0918a495b1c6b188a0fda3211 Mon Sep 17 00:00:00 2001 From: morrieinmaas <10432473+morrieinmaas@users.noreply.github.com> Date: Fri, 14 Aug 2026 13:30:06 +0200 Subject: [PATCH 1/3] feat: 14-08-2026 release with the blip rewrites assigned to Moritz Adds a new radar/2026-08-14/ release folder with new versions of the eight blips assigned to @morrieinmaas in the Tech Radar Blips Review Table, so the previously published 2026-04-23 release and the older history stay intact. - bdd: rewritten around the collaborative practice; Cucumber and Playwright moved out of the blip as the review asks, title becomes "BDD" - databricks: trial -> adopt; adds vendor lock-in and US cloud provider dependency considerations, and an alternatives section covering our FOSS lakehouse work - domain-driven-design: gains a "Visualising the model with C4" section, so the C4 Model blip is folded in here rather than standing on its own - event-driven-architecture: reframed as an approach rather than a checklist, deliberately without vendor-specific examples - graphql: adopt -> hold; we still run it in production and can support clients who need it, but would not pick it for a new project - kubernetes: back on the radar (featured); containerising the stack as the baseline, then self-hosted to serverless containers on managed platforms - redis: Valkey becomes the preferred key-value store, Redis stays available where a client wants it; title becomes "Valkey / Redis" - tanstack-query: rewritten now that it is independent of React The C4 Model blip is removed and the link to it from the 2022-05-17 DDD version is unlinked, so no internal links break. --- radar/2022-05-17/domain-driven-design.md | 2 +- radar/2022-12-05/c4-model.md | 10 -------- radar/2026-08-14/bdd.md | 14 +++++++++++ radar/2026-08-14/databricks.md | 22 ++++++++++++++++++ radar/2026-08-14/domain-driven-design.md | 23 +++++++++++++++++++ radar/2026-08-14/event-driven-architecture.md | 21 +++++++++++++++++ radar/2026-08-14/graphql.md | 14 +++++++++++ radar/2026-08-14/kubernetes.md | 18 +++++++++++++++ radar/2026-08-14/redis.md | 12 ++++++++++ radar/2026-08-14/tanstack-query.md | 12 ++++++++++ 10 files changed, 137 insertions(+), 11 deletions(-) delete mode 100644 radar/2022-12-05/c4-model.md create mode 100644 radar/2026-08-14/bdd.md create mode 100644 radar/2026-08-14/databricks.md create mode 100644 radar/2026-08-14/domain-driven-design.md create mode 100644 radar/2026-08-14/event-driven-architecture.md create mode 100644 radar/2026-08-14/graphql.md create mode 100644 radar/2026-08-14/kubernetes.md create mode 100644 radar/2026-08-14/redis.md create mode 100644 radar/2026-08-14/tanstack-query.md diff --git a/radar/2022-05-17/domain-driven-design.md b/radar/2022-05-17/domain-driven-design.md index e3d034e..466a785 100644 --- a/radar/2022-05-17/domain-driven-design.md +++ b/radar/2022-05-17/domain-driven-design.md @@ -5,7 +5,7 @@ quadrant: methods-and-patterns featured: true --- -Domain-driven design (DDD) is a software design approach focusing on [modelling](/tools/c4-model) software to match a +Domain-driven design (DDD) is a software design approach focusing on modelling software to match a domain according to input from that domain's experts. Domain-driven design is predicated on the following goals: diff --git a/radar/2022-12-05/c4-model.md b/radar/2022-12-05/c4-model.md deleted file mode 100644 index a9a4010..0000000 --- a/radar/2022-12-05/c4-model.md +++ /dev/null @@ -1,10 +0,0 @@ ---- -title: "C4 Model" -ring: adopt -quadrant: tools -featured: true ---- - -We use the C4 Model for visualising software architecture. By doing so we also use the C4 vocabulary when describing software architectures. We focus on System Context and Container diagrams and not so much on the low-level Component and Code diagrams. - -Having used UML in the (distant) past and free-format diagramming since then we feel that we miss a level of consistency in both visualising as well as describing our software architectures. We think that C4 brings us just enough consolidation but still leaves for enough flexibility on how to use it. \ No newline at end of file diff --git a/radar/2026-08-14/bdd.md b/radar/2026-08-14/bdd.md new file mode 100644 index 0000000..9144247 --- /dev/null +++ b/radar/2026-08-14/bdd.md @@ -0,0 +1,14 @@ +--- +title: "BDD" +ring: adopt +quadrant: methods-and-patterns +featured: true +--- + +Behaviour-Driven Development (BDD) is a collaborative approach to software development that bridges the communication gap between business and IT. It keeps teams focused on the behaviour that matters to the people using the software, described from their perspective rather than from the implementation's. + +The value of BDD is in the conversation. Writing scenarios together with business stakeholders surfaces disagreement about requirements early, while it is still cheap to resolve. The automated tests that follow are a by-product of that shared understanding, not the point of it. + +We write those scenarios in Gherkin, whose Given/When/Then structure is deliberately close to natural language. A scenario stays readable for non-technical stakeholders while remaining precise enough to execute. + +BDD is not a one-size-fits-all solution. It works best when the team is genuinely committed to the collaborative approach and when complex business rules need to be understood by everyone involved. Where the requirements are simple, or where the only readers are engineers, the ceremony costs more than it returns. diff --git a/radar/2026-08-14/databricks.md b/radar/2026-08-14/databricks.md new file mode 100644 index 0000000..6a0f680 --- /dev/null +++ b/radar/2026-08-14/databricks.md @@ -0,0 +1,22 @@ +--- +title: "Databricks" +ring: adopt +quadrant: tools +featured: true +--- + +[Databricks](https://www.databricks.com/) is a unified analytics platform that brings data engineering, data science and business analytics into a single workspace. Built by the original creators of Apache Spark, it covers large-scale data processing, machine learning workflows and real-time analytics. + +We have extensive Databricks knowledge in house, which is why it moves to adopt. It is also an established choice among our clients, so a good part of this work is joining teams where Databricks is already running and helping them get more out of it. + +### Considerations + +- **Vendor lock-in:** Databricks is a commercial platform. Pipelines written against its proprietary features are not trivially portable, and both cost and roadmap sit with a single vendor. + +- **US cloud provider dependency:** Databricks runs on the US hyperscalers. For clients with digital sovereignty requirements that dependency has to be weighed explicitly — see [European Sovereign Cloud](/platforms-and-operations/european-sovereign-cloud). + +### Alternatives + +Databricks is not the only thing we offer. We also have extensive knowledge of open source lakehouse setups, and for our own projects that is what we prefer: it avoids the lock-in and the sovereignty questions, at the cost of assembling and operating more of the stack ourselves. + +For client work we evaluate which of the two is the better fit — what the client already runs, the engineering capacity available to operate it, and the budget all weigh in. Neither is the default answer. diff --git a/radar/2026-08-14/domain-driven-design.md b/radar/2026-08-14/domain-driven-design.md new file mode 100644 index 0000000..9e1b571 --- /dev/null +++ b/radar/2026-08-14/domain-driven-design.md @@ -0,0 +1,23 @@ +--- +title: "Domain Driven Design (DDD)" +ring: adopt +quadrant: methods-and-patterns +featured: true +--- + +Domain-driven design (DDD) is a software design approach focusing on modelling software to match a domain according to input from that domain's experts. + +Domain-driven design is predicated on the following goals: + +- placing the project's primary focus on the core domain and domain logic +- basing complex designs on a model of the domain +- initiating a creative collaboration between technical and domain experts to iteratively refine a +conceptual model that addresses particular domain problems. + +### Visualising the model with C4 + +A model is only worth something if it can be shared, so we use the [C4 model](https://c4model.com/) to visualise the architectures we design, and the C4 vocabulary to describe them. + +We focus on the System Context and Container levels and use the lower-level Component and Code diagrams sparingly. Those top two levels are where the DDD concepts become visible: where the bounded contexts sit, where the boundaries between them run, and which language is used inside each. + +Having used UML in the distant past and free-format diagramming since then, we found we were missing consistency in both visualising and describing our architectures. C4 gives us enough consolidation to be consistent, while still leaving enough flexibility in how we apply it. diff --git a/radar/2026-08-14/event-driven-architecture.md b/radar/2026-08-14/event-driven-architecture.md new file mode 100644 index 0000000..b82cbc9 --- /dev/null +++ b/radar/2026-08-14/event-driven-architecture.md @@ -0,0 +1,21 @@ +--- +title: "Event-driven Architecture" +ring: adopt +quadrant: methods-and-patterns +featured: true +--- + +Event-driven architecture is less a technology choice than a way of thinking about systems. Rather than components calling each other to make things happen, they publish facts about what has happened, and other components decide for themselves what to do with them. + +That inversion is the point. A producer stops needing to know who its consumers are, which means new behaviour can be added by adding a subscriber instead of by changing the thing that emits the event. Systems built this way tend to stay easier to extend as they grow. + +We use this approach where the problem calls for it: + +- when several parts of a system need to react to the same thing happening +- when producers and consumers should be able to evolve independently of each other +- when the sequence of what happened is itself valuable, for auditing, for replay, or for rebuilding state +- when load between components varies enough that decoupling them in time is worth something + +It is not free. Asynchronous flows are harder to follow than a call stack. Delivery is typically at-least-once, so consumers have to be idempotent. Eventual consistency needs to be a deliberate decision rather than a surprise, and debugging spans several components, which means tracing has to be in place from the start rather than added once something goes wrong. + +As with any architecture, the right answer is the one that fits the problem. Event-driven is one of the approaches we reach for deliberately, not a default we apply everywhere. diff --git a/radar/2026-08-14/graphql.md b/radar/2026-08-14/graphql.md new file mode 100644 index 0000000..954e7f1 --- /dev/null +++ b/radar/2026-08-14/graphql.md @@ -0,0 +1,14 @@ +--- +title: "GraphQL" +ring: hold +quadrant: languages-and-frameworks +featured: true +--- + +We have moved [GraphQL](https://graphql.org/) to hold. + +We have used GraphQL in a number of projects and found that in our context it tends to create more problems than it solves. The added complexity in caching, authorisation and schema governance has not paid off against the flexibility it gives us. + +Hold does not mean we have stopped. We still actively run GraphQL in production on a current project and keep the skills to do so, so we can support clients who already have it or who specifically need it. What it does mean is that we would not choose GraphQL again for a new project. There we prefer REST for frontend-backend integration. + +This is not a judgement on GraphQL as a technology. It is a judgement on how well it fits the kind of solutions we typically build. diff --git a/radar/2026-08-14/kubernetes.md b/radar/2026-08-14/kubernetes.md new file mode 100644 index 0000000..cf7aeea --- /dev/null +++ b/radar/2026-08-14/kubernetes.md @@ -0,0 +1,18 @@ +--- +title: "Kubernetes" +ring: adopt +quadrant: tools +featured: true +--- + +[Kubernetes](https://kubernetes.io/) is the industry standard for container orchestration and is offered as a managed service by every major cloud provider. + +Adopting it starts with something more basic: we containerise the stack. Containers are how we run software during development and how we ship it to every environment beyond that, which keeps what a developer runs locally close to what actually goes to production. + +How much orchestration a solution needs on top of that varies, and we work across the whole range: + +- **Self-hosted Kubernetes**, where a client needs full control over the cluster or has to run on their own infrastructure. +- **Managed Kubernetes**, where most of our solutions land. The declarative model and the ecosystem around it, without the burden of operating the control plane ourselves. +- **Serverless containers on managed platforms**, where a solution does not need a cluster at all and the platform scales containers directly. + +A mature managed Kubernetes offering is one of our criteria when assessing [European Sovereign Cloud](/platforms-and-operations/european-sovereign-cloud) providers, because it is a large part of what keeps workloads portable between them. diff --git a/radar/2026-08-14/redis.md b/radar/2026-08-14/redis.md new file mode 100644 index 0000000..48bd8b9 --- /dev/null +++ b/radar/2026-08-14/redis.md @@ -0,0 +1,12 @@ +--- +title: "Valkey / Redis" +ring: adopt +quadrant: platforms-and-operations +featured: true +--- + +We use an in-memory key-value data store for specific cases such as a custom cache or queue management solution. In those cases a relational database would be overkill and not a good fit. + +For new solutions we prefer [Valkey](https://valkey.io/). Valkey is the Linux Foundation fork created after Redis moved away from an open source licence, and we think it is now the better of the two: development has been more active, the performance work has gone further, and its governance is genuinely open. It is API-compatible with Redis, so existing clients, libraries and tooling continue to work, and several cloud providers now offer it as their default. + +[Redis](https://redis.io/) remains a solid choice and we are happy to use it where a client prefers or requires it, or where it is already running. diff --git a/radar/2026-08-14/tanstack-query.md b/radar/2026-08-14/tanstack-query.md new file mode 100644 index 0000000..78c924c --- /dev/null +++ b/radar/2026-08-14/tanstack-query.md @@ -0,0 +1,12 @@ +--- +title: "TanStack Query" +ring: adopt +quadrant: languages-and-frameworks +featured: true +--- + +[TanStack Query](https://tanstack.com/query/) _(formerly known as React Query)_ is our preferred library for managing server state in the frontends of our web applications. + +It is worth being precise about what it does. It is not general-purpose state management; it is a cache for data that lives on the server. Fetching, caching, background revalidation, deduplication of in-flight requests and invalidation are all handled for you, which removes a category of hand-rolled code that used to end up in every project. + +Despite the old name, TanStack Query is no longer React-specific. It is built on a framework-agnostic core with adapters for the other major frontend frameworks, so the same approach — and most of the same mental model — carries across the frontend stacks we work in. From b664f42b0bd2d24f3e83e24f4e51f82bd34670fc Mon Sep 17 00:00:00 2001 From: morrieinmaas <10432473+morrieinmaas@users.noreply.github.com> Date: Fri, 14 Aug 2026 13:51:16 +0200 Subject: [PATCH 2/3] fix(radar): apply review feedback on the 14-08-2026 rewrites Detail pages render every version of a blip stacked under its own date, so the new text has to read coherently next to the older entries. It did not everywhere. - domain-driven-design: the new version repeated the 2022 opening paragraph and goals list verbatim, which read as a copy-paste error with both on one page. It now carries only the C4 material, which is what actually changed. - event-driven-architecture: condensed. The 2021 version already explains producer/consumer decoupling and the 2022 version already lists when to consider it, so the new version now states the approach once and keeps only what is new: the framing, the stance, and the costs. - event-driven-architecture (2022 version): drop the recommendation to use Event Sourcing, a blip removed in #106, and fix the "Even-Driven" typo. - bdd (2023 version): drop Cucumber, which we no longer use. Playwright stays, since we still use it extensively and it has its own blip. --- radar/2022-05-17/event-driven-architecture.md | 3 +-- radar/2023-08-01/bdd.md | 8 +++----- radar/2026-08-14/domain-driven-design.md | 9 --------- radar/2026-08-14/event-driven-architecture.md | 13 ++----------- 4 files changed, 6 insertions(+), 27 deletions(-) diff --git a/radar/2022-05-17/event-driven-architecture.md b/radar/2022-05-17/event-driven-architecture.md index 5e4b1a1..b84e4b7 100644 --- a/radar/2022-05-17/event-driven-architecture.md +++ b/radar/2022-05-17/event-driven-architecture.md @@ -12,5 +12,4 @@ architecture style](https://docs.microsoft.com/en-us/azure/architecture/guide/ar - Real-time processing with minimum time lag. - Complex event processing, such as pattern matching or aggregation over time windows. - High volume and high velocity of data, such as IoT. - Be aware of the complexities and potential pitfalls involved when adopting this architecture. When - using Even-Driven Architectures consider using Event Sourcing. \ No newline at end of file + Be aware of the complexities and potential pitfalls involved when adopting this architecture. \ No newline at end of file diff --git a/radar/2023-08-01/bdd.md b/radar/2023-08-01/bdd.md index 0e1bbbd..1016af3 100644 --- a/radar/2023-08-01/bdd.md +++ b/radar/2023-08-01/bdd.md @@ -1,5 +1,5 @@ --- -title: "BDD with Gherkin, Cucumber" +title: "BDD with Gherkin" ring: adopt quadrant: methods-and-patterns featured: true @@ -7,12 +7,10 @@ featured: true Behavior-Driven Development (BDD) is a collaborative approach to software development that bridges the communication gap between business and IT. BDD helps teams focus on delivering features that truly matter by emphasizing the behavior of an application from the end user's perspective. -[Gherkin](https://cucumber.io/docs/gherkin/) is Cucumber's language to define test cases. It's designed to be easy to read and lets you write scripts in a natural language style. - -[Cucumber](https://cucumber.io/) is a tool that supports BDD. It reads Gherkin documents and validates that the code performs as expected. +[Gherkin](https://cucumber.io/docs/gherkin/) is the language used to define test cases. It's designed to be easy to read and lets you write scripts in a natural language style. [Playwright](/tools/playwright) is a powerful tool for end-to-end testing that complements BDD approaches. With support for multiple browsers, headless testing, and API controls, Playwright offers robust testing capabilities for both simple and complex applications. -Adopting BDD, Gherkin, Cucumber and [Playwright](/tools/playwright) in our workflow allows for a clear understanding and discussion of requirements across the team, including non-technical stakeholders. This fosters collaboration and helps prevent miscommunication. Automated testing through Gherkin, Cucumber and Playwright also encourages the development of more robust, bug-free software. +Adopting BDD, Gherkin and [Playwright](/tools/playwright) in our workflow allows for a clear understanding and discussion of requirements across the team, including non-technical stakeholders. This fosters collaboration and helps prevent miscommunication. Automated testing through Gherkin and Playwright also encourages the development of more robust, bug-free software. However, BDD is not a one-size-fits-all solution. It works best when the team is committed to the collaborative approach and when complex business rules need to be understood by all stakeholders. diff --git a/radar/2026-08-14/domain-driven-design.md b/radar/2026-08-14/domain-driven-design.md index 9e1b571..673af8f 100644 --- a/radar/2026-08-14/domain-driven-design.md +++ b/radar/2026-08-14/domain-driven-design.md @@ -5,15 +5,6 @@ quadrant: methods-and-patterns featured: true --- -Domain-driven design (DDD) is a software design approach focusing on modelling software to match a domain according to input from that domain's experts. - -Domain-driven design is predicated on the following goals: - -- placing the project's primary focus on the core domain and domain logic -- basing complex designs on a model of the domain -- initiating a creative collaboration between technical and domain experts to iteratively refine a -conceptual model that addresses particular domain problems. - ### Visualising the model with C4 A model is only worth something if it can be shared, so we use the [C4 model](https://c4model.com/) to visualise the architectures we design, and the C4 vocabulary to describe them. diff --git a/radar/2026-08-14/event-driven-architecture.md b/radar/2026-08-14/event-driven-architecture.md index b82cbc9..e173ed2 100644 --- a/radar/2026-08-14/event-driven-architecture.md +++ b/radar/2026-08-14/event-driven-architecture.md @@ -7,15 +7,6 @@ featured: true Event-driven architecture is less a technology choice than a way of thinking about systems. Rather than components calling each other to make things happen, they publish facts about what has happened, and other components decide for themselves what to do with them. -That inversion is the point. A producer stops needing to know who its consumers are, which means new behaviour can be added by adding a subscriber instead of by changing the thing that emits the event. Systems built this way tend to stay easier to extend as they grow. +We use this approach, and we use it deliberately. It is not free: asynchronous flows are harder to follow than a call stack, delivery is typically at-least-once so consumers have to be idempotent, eventual consistency has to be a decision rather than a surprise, and debugging spans several components, which means tracing has to be in place from the start rather than added once something goes wrong. -We use this approach where the problem calls for it: - -- when several parts of a system need to react to the same thing happening -- when producers and consumers should be able to evolve independently of each other -- when the sequence of what happened is itself valuable, for auditing, for replay, or for rebuilding state -- when load between components varies enough that decoupling them in time is worth something - -It is not free. Asynchronous flows are harder to follow than a call stack. Delivery is typically at-least-once, so consumers have to be idempotent. Eventual consistency needs to be a deliberate decision rather than a surprise, and debugging spans several components, which means tracing has to be in place from the start rather than added once something goes wrong. - -As with any architecture, the right answer is the one that fits the problem. Event-driven is one of the approaches we reach for deliberately, not a default we apply everywhere. +As with any architecture, the right answer is the one that fits the problem. Event-driven is one of the approaches we reach for, not a default we apply everywhere. From 27297806b3f44ba87fea95b16ddac64cf84f0c88 Mon Sep 17 00:00:00 2001 From: morrieinmaas <10432473+morrieinmaas@users.noreply.github.com> Date: Fri, 14 Aug 2026 14:34:23 +0200 Subject: [PATCH 3/3] refactor(radar): drop the C4/DDD fold and sharpen three rewrites - c4-model, domain-driven-design: reverted. Folding C4 Model into DDD touches Edgar's row, and he will pick that up himself, so it does not belong in this PR. C4 Model is restored untouched, as is the DDD link to it. This PR now covers 7 of the 8 assigned blips and no longer depends on anyone else. - tanstack-query: says why we rate it rather than only what it does, and notes that the other TanStack libraries are of the same quality and in use. - redis, kubernetes: both opened by restating their previous version's first sentence. They now lead with what actually changed. --- radar/2022-05-17/domain-driven-design.md | 2 +- radar/2022-12-05/c4-model.md | 10 ++++++++++ radar/2026-08-14/domain-driven-design.md | 14 -------------- radar/2026-08-14/kubernetes.md | 4 +--- radar/2026-08-14/redis.md | 4 ++-- radar/2026-08-14/tanstack-query.md | 8 +++++--- 6 files changed, 19 insertions(+), 23 deletions(-) create mode 100644 radar/2022-12-05/c4-model.md delete mode 100644 radar/2026-08-14/domain-driven-design.md diff --git a/radar/2022-05-17/domain-driven-design.md b/radar/2022-05-17/domain-driven-design.md index 466a785..e3d034e 100644 --- a/radar/2022-05-17/domain-driven-design.md +++ b/radar/2022-05-17/domain-driven-design.md @@ -5,7 +5,7 @@ quadrant: methods-and-patterns featured: true --- -Domain-driven design (DDD) is a software design approach focusing on modelling software to match a +Domain-driven design (DDD) is a software design approach focusing on [modelling](/tools/c4-model) software to match a domain according to input from that domain's experts. Domain-driven design is predicated on the following goals: diff --git a/radar/2022-12-05/c4-model.md b/radar/2022-12-05/c4-model.md new file mode 100644 index 0000000..a9a4010 --- /dev/null +++ b/radar/2022-12-05/c4-model.md @@ -0,0 +1,10 @@ +--- +title: "C4 Model" +ring: adopt +quadrant: tools +featured: true +--- + +We use the C4 Model for visualising software architecture. By doing so we also use the C4 vocabulary when describing software architectures. We focus on System Context and Container diagrams and not so much on the low-level Component and Code diagrams. + +Having used UML in the (distant) past and free-format diagramming since then we feel that we miss a level of consistency in both visualising as well as describing our software architectures. We think that C4 brings us just enough consolidation but still leaves for enough flexibility on how to use it. \ No newline at end of file diff --git a/radar/2026-08-14/domain-driven-design.md b/radar/2026-08-14/domain-driven-design.md deleted file mode 100644 index 673af8f..0000000 --- a/radar/2026-08-14/domain-driven-design.md +++ /dev/null @@ -1,14 +0,0 @@ ---- -title: "Domain Driven Design (DDD)" -ring: adopt -quadrant: methods-and-patterns -featured: true ---- - -### Visualising the model with C4 - -A model is only worth something if it can be shared, so we use the [C4 model](https://c4model.com/) to visualise the architectures we design, and the C4 vocabulary to describe them. - -We focus on the System Context and Container levels and use the lower-level Component and Code diagrams sparingly. Those top two levels are where the DDD concepts become visible: where the bounded contexts sit, where the boundaries between them run, and which language is used inside each. - -Having used UML in the distant past and free-format diagramming since then, we found we were missing consistency in both visualising and describing our architectures. C4 gives us enough consolidation to be consistent, while still leaving enough flexibility in how we apply it. diff --git a/radar/2026-08-14/kubernetes.md b/radar/2026-08-14/kubernetes.md index cf7aeea..5064603 100644 --- a/radar/2026-08-14/kubernetes.md +++ b/radar/2026-08-14/kubernetes.md @@ -5,9 +5,7 @@ quadrant: tools featured: true --- -[Kubernetes](https://kubernetes.io/) is the industry standard for container orchestration and is offered as a managed service by every major cloud provider. - -Adopting it starts with something more basic: we containerise the stack. Containers are how we run software during development and how we ship it to every environment beyond that, which keeps what a developer runs locally close to what actually goes to production. +Adopting [Kubernetes](https://kubernetes.io/) starts with something more basic: we containerise the stack. Containers are how we run software during development and how we ship it to every environment beyond that, which keeps what a developer runs locally close to what actually goes to production. How much orchestration a solution needs on top of that varies, and we work across the whole range: diff --git a/radar/2026-08-14/redis.md b/radar/2026-08-14/redis.md index 48bd8b9..bb14239 100644 --- a/radar/2026-08-14/redis.md +++ b/radar/2026-08-14/redis.md @@ -5,8 +5,8 @@ quadrant: platforms-and-operations featured: true --- -We use an in-memory key-value data store for specific cases such as a custom cache or queue management solution. In those cases a relational database would be overkill and not a good fit. +For new solutions we now prefer [Valkey](https://valkey.io/) over Redis. -For new solutions we prefer [Valkey](https://valkey.io/). Valkey is the Linux Foundation fork created after Redis moved away from an open source licence, and we think it is now the better of the two: development has been more active, the performance work has gone further, and its governance is genuinely open. It is API-compatible with Redis, so existing clients, libraries and tooling continue to work, and several cloud providers now offer it as their default. +Valkey is the Linux Foundation fork created after Redis moved away from an open source licence, and we think it is now the better of the two: development has been more active, the performance work has gone further, and its governance is genuinely open. It is API-compatible with Redis, so existing clients, libraries and tooling continue to work, and several cloud providers now offer it as their default. [Redis](https://redis.io/) remains a solid choice and we are happy to use it where a client prefers or requires it, or where it is already running. diff --git a/radar/2026-08-14/tanstack-query.md b/radar/2026-08-14/tanstack-query.md index 78c924c..b4d46b0 100644 --- a/radar/2026-08-14/tanstack-query.md +++ b/radar/2026-08-14/tanstack-query.md @@ -5,8 +5,10 @@ quadrant: languages-and-frameworks featured: true --- -[TanStack Query](https://tanstack.com/query/) _(formerly known as React Query)_ is our preferred library for managing server state in the frontends of our web applications. +[TanStack Query](https://tanstack.com/query/) _(formerly known as React Query)_ is hands down one of the best ways to handle queries and application state in JavaScript and TypeScript applications, and it remains our preferred choice for it. -It is worth being precise about what it does. It is not general-purpose state management; it is a cache for data that lives on the server. Fetching, caching, background revalidation, deduplication of in-flight requests and invalidation are all handled for you, which removes a category of hand-rolled code that used to end up in every project. +It takes care of fetching, caching, background revalidation, deduplication of in-flight requests and invalidation. That removes a whole category of hand-rolled code that used to end up in every project, along with the bugs that came with it. -Despite the old name, TanStack Query is no longer React-specific. It is built on a framework-agnostic core with adapters for the other major frontend frameworks, so the same approach — and most of the same mental model — carries across the frontend stacks we work in. +Despite the old name, TanStack Query is no longer React-specific. It is built on a framework-agnostic core with adapters for the other major frontend frameworks, so the same approach and most of the same mental model carry across the frontend stacks we work in. + +The rest of the [TanStack](https://tanstack.com/) family is worth knowing too. Libraries such as TanStack Table, Router, Form and Virtual are of the same quality and share the same design philosophy, and we use them where they fit.