chore: sync radar with INFO technical decisions wiki - #105
Conversation
edgarvonk
left a comment
edgarvonk
left a comment
There was a problem hiding this comment.
nice one! left some comments for us to ponder
| @@ -0,0 +1,22 @@ | |||
| --- | |||
| title: "GitHub Dependabot" | |||
There was a problem hiding this comment.
This one is no longer valid. We now prefer Renovate over Dependabot for good reasons. I seem to remember we documented our reasoning somewhere as well.. but maybe not.
I think we should not add Dependabot but rather update our Renovate blip (https://techradar.info.nl/tools/renovate/) and add it to adopt. Dependabot is still fine as second choice I would say. Any such tool is much better than not any such tool. :-)
I think @niorg can best document the reasoning why we prefer Renovate?
There was a problem hiding this comment.
that would be nice. for common ground components other than ZAC we currently use dependabot (and snyk) so it would probably be good to consolidate those
| ### Considerations at INFO | ||
|
|
||
| - Applies to new client solutions; existing solutions are not migrated for the sake of this preference. | ||
| - Deviation is fine when an agnostic open-market standard is a genuinely better fit, or when the client requires it. |
There was a problem hiding this comment.
Common Ground and Dimpact explicitly choose such agnostic open-market standards and avoid cloud vendor native services as much as possible, in order to minimize dependency, sacrificing some vendor specific functionality (I guess). For this reason I'm a bit in doubt if we should still include this blip now.. What do others feel about this? E.g. @felixcicatt
There was a problem hiding this comment.
I'm all for vendor agnostic tbh.
| - Applies to new client solutions; existing solutions are not migrated for the sake of this preference. | ||
| - Deviation is fine when an agnostic open-market standard is a genuinely better fit, or when the client requires it. | ||
| - Specific refinements override this default — see [PostgreSQL](/platforms-and-operations/postgresql/), where we explicitly prefer the open standard over cloud-native relational alternatives. | ||
| - Cross-team skill transfer is harder when services are vendor-specific; the broader concepts (containers, queues, object storage) still translate. |
There was a problem hiding this comment.
Doesn't this contradict the previous statement/paragraph
Why native over agnostic?
There was a problem hiding this comment.
I think we should rewrite this blip and completely reverse it. ;-) Or maybe just don't add it at all. Not sure if it even adds value at this point in time.
There was a problem hiding this comment.
unsure either. Generally speaking my take is as follows: In the vast majority of cases vendor specific products are mainly implementations of concepts that open-source tools also do, but with a ribbon on it, and some conveniences on top. As a team/company it's imho better to properly understand k8s for example than managed k8s in Azure. If you understand the general concepts of computing the learning curve between the vendor specific implementations is in most cases trivial. And much easier this way round than knowing one AWS tool very well, but not being able to do the same on some other cloud provider, just because the conveniences offered by the polished vendor product robbed one of the need to look up how things actually work
There was a problem hiding this comment.
Agreed. I don't know when we originally came to this conclusion that's written on the wiki, but I'd say the default should be open standards, and whenever there are good reasons to pick something vendor specific for a project those choices should be documented
morrieinmaas
left a comment
morrieinmaas
left a comment
There was a problem hiding this comment.
Great job overall @xiduzo 🚀 - left a few pokey and provocative comments
| @@ -0,0 +1,23 @@ | |||
| --- | |||
There was a problem hiding this comment.
makes a ton of sense
|
|
||
| - Applies to new client solutions; existing solutions are not migrated for the sake of this preference. | ||
| - Deviation is fine when an agnostic open-market standard is a genuinely better fit, or when the client requires it. | ||
| - Specific refinements override this default — see [PostgreSQL](/platforms-and-operations/postgresql/), where we explicitly prefer the open standard over cloud-native relational alternatives. |
There was a problem hiding this comment.
I think an open standard can still be cloud-native, right? Particularly for postgres, for which I think we prefer the cloudnative postgres operator now?
| - Specific refinements override this default — see [PostgreSQL](/platforms-and-operations/postgresql/), where we explicitly prefer the open standard over cloud-native relational alternatives. | |
| - Specific refinements override this default — see [PostgreSQL](/platforms-and-operations/postgresql/), where we explicitly prefer the open standard over vendor-native relational alternatives. |
| - Applies to new client solutions; existing solutions are not migrated for the sake of this preference. | ||
| - Deviation is fine when an agnostic open-market standard is a genuinely better fit, or when the client requires it. | ||
| - Specific refinements override this default — see [PostgreSQL](/platforms-and-operations/postgresql/), where we explicitly prefer the open standard over cloud-native relational alternatives. | ||
| - Cross-team skill transfer is harder when services are vendor-specific; the broader concepts (containers, queues, object storage) still translate. |
There was a problem hiding this comment.
Agreed. I don't know when we originally came to this conclusion that's written on the wiki, but I'd say the default should be open standards, and whenever there are good reasons to pick something vendor specific for a project those choices should be documented
| @@ -0,0 +1,23 @@ | |||
| --- | |||
There was a problem hiding this comment.
Is support for multiple js runtimes something to consider? Or are we all in on nodejs
| @@ -0,0 +1,22 @@ | |||
| --- | |||
| title: "GitHub Dependabot" | |||
There was a problem hiding this comment.
that would be nice. for common ground components other than ZAC we currently use dependabot (and snyk) so it would probably be good to consolidate those
4 participants
Summary
radar/2026-05-13/snapshot with three entries that were documented in the wiki but missing from the radar:fastify.md— adopt, languages-and-frameworkscloud-vendor-native-services.md— adopt, platforms-and-operationsdependabot.md— adopt, tools.claude/skills/radar-*skill files used to scaffold and review entries.Existing entries that already aligned with the wiki (react, typescript, graphql, aws, nodejs, serverless-framework, python, postgresql, github, git-rebase-and-merge-merge-strategy) are left untouched — the radar is differential and authoritative when it disagrees with the wiki.
Superseded wiki decisions (kotlin, javascript, express, ktor, react-native's old hold note) are already represented in earlier dated snapshots; no new files needed.
Test plan
🤖 Generated with Claude Code