adopttrialassessholdcodeTypeScriptReactRedux ToolkitRTK Querydinero.jstypeboxBullCypressESLintFast CheckJestMSWPinoPrettierReduxStyled Componen...swc-jesttesting libraryts-jestPlain JavaScrip...AJVSuretypeyupzodadopttrialassessholdplatformsGitnpm scriptsAWSAWS CDKAmplifyGoogle SheetsMongoDBRedisStorybookChili PublishGulpTerraformadopttrialassessholdtechniquesMonorepoFeature flagsLearning Journe...Hexagonal archi...Folder structur...Naming Conventi...Bounded Context...Unified input v...BDDMob programmingTDDReach & Impact ...Layered archite...Microservice ar...MultireposRICE methodCost of DelayTotal impact pr...adopttrialassessholdtoolsGitHubLaunchDarklyPostHogChromaticCloudWatchDovetailFigmaOpen APISentryADRsBitBucketGoogle Analytic...HotJar

List of ADRs

accepted

ADRs

  • Moved ADRs to adopt

Git

  • Moved Git to adopt

TypeScript

  • Moved TypeScript to adopt
  • Moved Plain JavaScript to hold

React

  • Moved React to adopt

npm scripts

  • Moved npm scripts to adopt
  • Moved Gulp to hold

GitHub

  • Moved GitHub to adopt
  • Moved BitBucket to hold

Monorepo via Rush and pnpm

  • Moved Monorepo to adopt
  • Moved Multirepos to hold

Feature flags with LaunchDarkly

  • Moved Feature flags to adopt
  • Moved LaunchDarkly to adopt

Infrastructure on AWS

  • Moved AWS to adopt

Choosing dependencies

    Deciding on ADRs

      Infrastructure as code via AWS CDK

      • Moved AWS CDK to adopt
      • Moved Terraform to hold

      Frontend component intercommunication

      • Moved Redux Toolkit to adopt

      Internal product announcements

        RTK Query

        • Moved RTK Query to adopt

        Product Analytics via PostHog

        • Moved PostHog to adopt
        • Moved Google Analytics to hold
        • Moved HotJar to hold

        Learning Journeys

        • Moved Learning Journeys to adopt

        Hexagonal architecture

        • Moved Hexagonal architecture to adopt
        • Moved Layered architecture to assess
        • Moved Microservice architecture to assess

        Application log retention

          FE Observability

          • Moved Sentry to assess

          Reach & Impact prioritization

          • Moved Reach & Impact prioritization to trial
          • Moved RICE method to hold
          • Moved Cost of Delay to hold
          • Moved Total impact prioritization to hold

          Remove Barrel Files

            Firefighter

              Artillery load testing toolkit

              • Moved ADRs to assess

              Dinero.js

              • Moved dinero.js to adopt

              Design Editor

              • Moved Chili Publish to assess

              Folder structure and file naming conventions

              • Moved Folder structure and file naming conventions to adopt

              Naming Conventions for AWS CDK Resources

              • Moved AWS CDK to adopt
              • Moved Naming Conventions for AWS CDK Resources to adopt

              Service documentation

              • Moved Bounded Context Canvas to adopt

              Unified input validation

              • Moved Unified input validation to adopt
              • Moved typebox to adopt
              • Moved AJV to hold
              • Moved Suretype to hold
              • Moved yup to hold
              • Moved zod to hold

              How to use this

              These are the public optilyz Tech Radar and Architectural Decision Records.

              Architectural principles

              The following principles are the base for our architectural decisions:

              We are not a platform company

              Our product does not require cutting-edge technology. If we can make a decision that allows us to outsource platform work to an external platform provider, we usually should choose that over something custom that we need to maintain ourselves.

              Optimize for cross-functional development

              Decide for what is easy to use and learn. Teams can’t afford to have specialists on each topic, so what we build on needs to be usable by non-specialists. This sometimes means choosing a solution that is easy to use, but less powerful or less optimized than other alternatives.

              Provide opinionated, composable building blocks

              The teams need to be able to work independently, but at the same time should not be burdened by the complexity of covering all the basics themselves. We decide for opinionated building blocks that should work in most situations, but can be swapped out by the teams in case they need something custom.

              How to use the Tech Radar

              The different rings show you how to interact with different technologies. If a technology you would like to use doesn't yet show up here, feel free to open a PR and add an ADR in the assess ring. Once it is promoted to `trial', you can use it for production code.

              Quadrants

              Quadrants roughly categorize the technologies, but the categorization doesn't have to be perfect and does not have any consequences except for making the radar more readable.

              Techniques

              These include elements of a software development process, such as experience design; and ways of structuring software, such as microservices.

              Tools

              Software to improve our way of working, or external components we use. Tools usually do not require us to make major changes to our code to be able to use them.

              Platforms

              Things that we build software on top of such as IaaS like AWS, or generic kinds of platforms like hybrid clouds.

              Code

              Programming languages and frameworks like TypeScript, or React. Also includes libraries with often used functionality, e.g. class-validator for validation.

              Rings

              Rings indicate whether you should be using a technology or not. Other than quadrants, they have strong implications, and which ring a technology is in matters a lot.

              Hold

              These are technologies we are still using, but that we are phasing out. Do not continue working with these technologies, and, instead, look for the replacement technologies that are in adopt. If you do need to continue using this technology, make every effort to move over as much as possible to the replacement technology first.

              Assess

              These technologies are proposed for introduction, but they are not yet assessed. You can try them in sandboxed environments, but not in production or development systems.

              Trial

              Technologies in trial are currently under consideration. You can use them in production, but be aware that we might decide against them in the next weeks, in which case you will have to remove them from our production systems.

              Adopt

              Technologies in adopt can and should be used. Not every technology is relevant for every project, and there might be multiple technologies for the same task to choose from.

              It makes sense to be aware of all technologies in Adopt and develop at least a basic understanding of them.

              Why is this public?

              We decided to share them publicly for transparency reasons. This way, candidates can inform themselves about the technologies we work with before having to join.