diff --git a/radar/2017-03-01/anypoint-platform.md b/radar/2017-03-01/anypoint-platform.md index 2b08ae2..3c9ef49 100644 --- a/radar/2017-03-01/anypoint-platform.md +++ b/radar/2017-03-01/anypoint-platform.md @@ -10,7 +10,7 @@ Anypoint provides tools to use Enterprise Integration Patterns (EAI) and has a h Anypoint Community Version is Open Source and contribution is possible. The platform is pluggable with own connectors. -Mulesoft is also driving the [RAML](/tools/raml.html) specification and related Open Source tools. +Mulesoft is also driving the [RAML](/languages-and-frameworks/raml/) specification and related Open Source tools. AOE is a Mulesoft Partner and we use both the Community and Enterprise Versions of Anypoint. We use Anypoint as an API Gateway to combine and transform data from multiple backends. diff --git a/radar/2017-03-01/api-first-design-approach.md b/radar/2017-03-01/api-first-design-approach.md index 9359c46..4611b8c 100644 --- a/radar/2017-03-01/api-first-design-approach.md +++ b/radar/2017-03-01/api-first-design-approach.md @@ -12,8 +12,8 @@ Furthermore, as one of the most important design aspects is consistency, one can It also helps speed up parallel implementation. A team that consumes the API can start working directly after the API design because it can easily be mocked. -There are several tools for modelling an API, but here at AOE we mainly use [RAML](/tools/raml.html) as it provides a rich set of tools for generating documentation, mocking and more. -For mocking we use [WireMock](/tools/wiremock.html), for example. +There are several tools for modelling an API, but here at AOE we mainly use [RAML](/languages-and-frameworks/raml/) as it provides a rich set of tools for generating documentation, mocking and more. +For mocking we use [WireMock](/tools/wiremock/), for example. Related to the "API-First" approach is the "Headless" approach where an existing application (with or without existing API) is used as a backend for a separate frontend. We used this with sucess for Magento-based E-Commerce platforms. diff --git a/radar/2017-03-01/babel.md b/radar/2017-03-01/babel.md index 67b2b2f..82741e2 100644 --- a/radar/2017-03-01/babel.md +++ b/radar/2017-03-01/babel.md @@ -32,4 +32,4 @@ The configuration is really simple due to the [plugin system](http://babeljs.io/ To know what you need you can practice ECMAScript 6 by doing it with [es6katas](http://es6katas.org/) and ask [caniuse](http://caniuse.com/). -If you are using [TypeScript](/languages-and-frameworks/typescript.html), Babel is not necessary since you already get the new features with TypeScript. \ No newline at end of file +If you are using [TypeScript](/languages-and-frameworks/typescript/), Babel is not necessary since you already get the new features with TypeScript. \ No newline at end of file diff --git a/radar/2017-03-01/consul.md b/radar/2017-03-01/consul.md index 2bf083c..5ac05ca 100644 --- a/radar/2017-03-01/consul.md +++ b/radar/2017-03-01/consul.md @@ -8,7 +8,7 @@ Consul is a lightweight service to provide a service discovery registry with fai The typical way to use it is that a consul master cluster takes care of the update and write processes and consul clients run locally on the apps host - data is shared across the complete Consul cluster. The data can be accessed by using DNS and HTTP APIs. -At AOE, we use Consul for settings distribution with consul-template as a way to do [Settings Injection](/methods-and-patterns/settings-injection.html) during deployment. -Consul is also used as service discovery between apps inside [microservice](/methods-and-patterns/microservices.html) environments. +At AOE, we use Consul for settings distribution with consul-template as a way to do [Settings Injection](/methods-and-patterns/settings-injection/) during deployment. +Consul is also used as service discovery between apps inside [microservice](/methods-and-patterns/microservices/) environments. With Vault there is another tool that can be used to manage and share secrets. diff --git a/radar/2017-03-01/decoupling-infrastructure-via-messaging.md b/radar/2017-03-01/decoupling-infrastructure-via-messaging.md index 9f14b6a..d7e6f3c 100644 --- a/radar/2017-03-01/decoupling-infrastructure-via-messaging.md +++ b/radar/2017-03-01/decoupling-infrastructure-via-messaging.md @@ -4,11 +4,11 @@ ring: trial quadrant: methods-and-patterns --- -In [Microservices](/methods-and-patterns/microservices.html) we have already covered the trend that modern architectures are moving away more and more from big monolithic applications to distributed software suites. +In [Microservices](/methods-and-patterns/microservices/) we have already covered the trend that modern architectures are moving away more and more from big monolithic applications to distributed software suites. The result of splitting our software and infrastructure in smaller parts, is the need to communicate with each other. This can be done by direct communication or by message-based asynchronouous communication. While synchronuous communication allows for more plannable "real-time" response times of the overall systems, asynchronouos communication increases the resilience and stability of the system significantly and allows one to use other integration and scaling patterns. However, it often comes with additional complexity. Most of the IaaS Cloud providers offer messaging services such as AWS SQS which provide the possibility to decouple our infrastructure via Messaging. -Also, we use [RabbitMQ](/tools/rabbitmq.html) as a Messaging and Broker solution within our applications. -The decision of using messaging and messaging patterns as an integration strategy can be made as part of [strategic design](/methods-and-patterns/strategic-domain-driven-design.html) considerations. +Also, we use [RabbitMQ](/tools/rabbitmq/) as a Messaging and Broker solution within our applications. +The decision of using messaging and messaging patterns as an integration strategy can be made as part of [strategic design](/methods-and-patterns/strategic-domain-driven-design/) considerations. diff --git a/radar/2017-03-01/docker.md b/radar/2017-03-01/docker.md index 3075aa2..929a084 100644 --- a/radar/2017-03-01/docker.md +++ b/radar/2017-03-01/docker.md @@ -13,6 +13,6 @@ In a DevOps environment, this helps a lot as we can run the exact same software Also, Docker allows us to keep our development setup much smaller and faster; instead of VirtualBox setups on a per-project base, we can compose our project development setup out of small containers. A CI environment building the containers allows us to package and test the whole environment instead of different software components on different runtimes in a much more stable way. -Backed by services such as [Kubernetes](/platforms-and-aoe-services/kubernetes.html), we can deploy Docker containers on a flexible infrastructure and enable our developers to test their software more easily in different environments. +Backed by services such as [Kubernetes](/platforms-and-aoe-services/kubernetes/), we can deploy Docker containers on a flexible infrastructure and enable our developers to test their software more easily in different environments. Here at AOE, we assess Docker in different projects to become more flexible and faster, which increases our focus on development of even better and more stable software. diff --git a/radar/2017-03-01/flow.md b/radar/2017-03-01/flow.md index 8683076..610b33f 100644 --- a/radar/2017-03-01/flow.md +++ b/radar/2017-03-01/flow.md @@ -12,4 +12,4 @@ We used Flow in a couple of projects and decided to put it on hold for the follo * limited documentation and community * development of the framework is closely coupled to the progress of the Neos project -Although it could be that some of the above-mentioned aspects have improved in the past, we decided to use other PHP frameworks such as [Symfony](http://symfony.com/) or other Languages (See [Go](/languages-and-frameworks/go-lang.html); [Play Framework](/languages-and-frameworks/play-framework.html); [Spring Boot](/languages-and-frameworks/spring-boot.html)) +Although it could be that some of the above-mentioned aspects have improved in the past, we decided to use other PHP frameworks such as [Symfony](http://symfony.com/) or other Languages (See [Go](/languages-and-frameworks/go-lang/); [Play Framework](/languages-and-frameworks/play-framework/); [Spring Boot](/languages-and-frameworks/spring-boot/)) diff --git a/radar/2017-03-01/gatling.md b/radar/2017-03-01/gatling.md index 7620f31..1146387 100644 --- a/radar/2017-03-01/gatling.md +++ b/radar/2017-03-01/gatling.md @@ -8,7 +8,7 @@ quadrant: tools Out of the box, Gatling comes with excellent support of the HTTP protocol that makes it a tool of choice for load testing any HTTP server. As the core engine is actually protocol agnostic, it is perfectly possible to implement support for other protocols. For example, Gatling currently also ships [JMS support](http://gatling.io/docs/current/). -Gatling is built with [Scala Lang](/languages-and-frameworks/scala-lang.html) and [Akka](/languages-and-frameworks/akka.html). By making good use of Scala's native language features (such as as the extensive type system), it makes writing tests feel natural and expressive, instead of writing load tests based on a DSL encoded in some special syntax. +Gatling is built with [Scala Lang](/languages-and-frameworks/scala-lang/) and [Akka](/languages-and-frameworks/akka/). By making good use of Scala's native language features (such as as the extensive type system), it makes writing tests feel natural and expressive, instead of writing load tests based on a DSL encoded in some special syntax. This allows us to use all native Scala features to work with, with the focus on the ability to structure your tests as pure code, and actually unit test your load tests. diff --git a/radar/2017-03-01/gradle.md b/radar/2017-03-01/gradle.md index 310d5e0..3f9fd61 100644 --- a/radar/2017-03-01/gradle.md +++ b/radar/2017-03-01/gradle.md @@ -11,4 +11,4 @@ It uses a Groovy-based DSL to declaratively model your problem domain (Build aut While providing plugins for building libs, apps and webapps in Java, Groovy and Scala out of the box it is not tied to the JVM as target platform, which is impressively shown by the native build support for C / C++. -At AOE, it is used in various places already: to build [Anypoint](/tools/anypoint-platform.html)- and [Spring Boot-](/languages-and-frameworks/spring-boot.html) based applications; to build Android Apps; to automate the creation of Jenkins Jobs; to create Docker images and Debian packages and also do some deployment scripting with it. +At AOE, it is used in various places already: to build [Anypoint](/tools/anypoint-platform/) and [Spring Boot](/languages-and-frameworks/spring-boot/) based applications; to build Android Apps; to automate the creation of Jenkins Jobs; to create Docker images and Debian packages and also do some deployment scripting with it. diff --git a/radar/2017-03-01/groovy.md b/radar/2017-03-01/groovy.md index 15a48c9..f415072 100644 --- a/radar/2017-03-01/groovy.md +++ b/radar/2017-03-01/groovy.md @@ -6,4 +6,4 @@ quadrant: languages-and-frameworks Groovy is a dynamically typed compiled language running on the JVM. It is easy to learn as it provides a familiar syntax for Java programmers, but also offers advanced features such as closures and makes some mandatory Java syntax requirements optional to enhance the conciseness of the code. These features make Groovy especially well-suited for scripting and domain-specific languages. This is used by popular tools such as Gradle or Spock. -At AOE, Groovy is used in many projects and areas. We use Gradle as a build system, we carry out unit and integration testing with Spock and Geb, we generate Jenkins jobs with JobDSL and we implement complete services with Groovy and [Spring Boot](/languages-and-frameworks/spring-boot.html). +At AOE, Groovy is used in many projects and areas. We use Gradle as a build system, we carry out unit and integration testing with Spock and Geb, we generate Jenkins jobs with JobDSL and we implement complete services with Groovy and [Spring Boot](/languages-and-frameworks/spring-boot/). diff --git a/radar/2017-03-01/microservices.md b/radar/2017-03-01/microservices.md index 39cea51..6b5e03c 100644 --- a/radar/2017-03-01/microservices.md +++ b/radar/2017-03-01/microservices.md @@ -15,7 +15,7 @@ The benefits we see are: * enabling better parallel work in big teams or multi-team projects * flexibility in deploying changes to production - by just deploying the changed service -Related patterns are [Strategic Domain Driven Design](/methods-and-patterns/strategic-domain-driven-design.html) as an approach to wisely cut your architecture according to useful bounded contexts and decide on the relevant communication and "translation" between the services. +Related patterns are [Strategic Domain Driven Design](/methods-and-patterns/strategic-domain-driven-design/) as an approach to wisely cut your architecture according to useful bounded contexts and decide on the relevant communication and "translation" between the services. In case you are looking for a small visualisation tool for your microservice architecture you might find [vistecture](https://github.com/AOEpeople/vistecture/) useful. -Also [Resilience thinking](/methods-and-patterns/resilience-thinking.html) is especially important when designing an application as a suite of microservices. +Also [Resilience thinking](/methods-and-patterns/resilience-thinking/) is especially important when designing an application as a suite of microservices. diff --git a/radar/2017-03-01/npm.md b/radar/2017-03-01/npm.md index 2f7b25c..6e3e333 100644 --- a/radar/2017-03-01/npm.md +++ b/radar/2017-03-01/npm.md @@ -6,21 +6,21 @@ quadrant: tools [npm](https://www.npmjs.com/) is one of, if not the most, popular package manager for JavaScript. Because of the big community, you can find nearly every dependency in npm. -Instead of other package managers such as [bower](/tools/bower.html), you have to write your packages as [modules](https://en.wikipedia.org/wiki/CommonJS). This unifies the way you have to use, test and, of course, understand dependencies. +Instead of other package managers such as [bower](/tools/bower/), you have to write your packages as [modules](https://en.wikipedia.org/wiki/CommonJS). This unifies the way you have to use, test and, of course, understand dependencies. -npm creates a tree for your dependencies and their nesting dependencies. Because of this, you don't need to handle version conflicts, since every dependency uses there own version of e.g. [webpack](/tools/webpack.html). +npm creates a tree for your dependencies and their nesting dependencies. Because of this, you don't need to handle version conflicts, since every dependency uses there own version of e.g. [webpack](/tools/webpack/). -With [shrinkwrap](https://docs.npmjs.com/cli/shrinkwrap) you have a robust tool to lock down and manage the versions of your dependencies - following the [Pin (external) dependencies](/methods-and-patterns/pin-external-dependencies.html) approach. +With [shrinkwrap](https://docs.npmjs.com/cli/shrinkwrap) you have a robust tool to lock down and manage the versions of your dependencies - following the [Pin (external) dependencies](/methods-and-patterns/pin-external-dependencies/) approach. For each package you have to classify your dependencies: - dependencies are needed for use without the need of pre compiling, e.g. [lodash](https://lodash.com/) -- devDependencies are needed for development only, e.g. testing frameworks or pre compiler e.g. [babel](/languages-and-frameworks/babel.html) +- devDependencies are needed for development only, e.g. testing frameworks or pre compiler e.g. [babel](/languages-and-frameworks/babel/) - peerDependencies you have to provide for using the package With [scripts](https://docs.npmjs.com/misc/scripts) you get support for the most common build lifecycle steps, e.g. build, start, test ... Other useful features: -- mirror support for your own repository (e.g. [artifactory](/platforms-and-aoe-services/artifactory.html)) -- can be used for server and client JavaScript development (see [node.js](/languages-and-frameworks/node-js.html) ) +- mirror support for your own repository (e.g. [artifactory](/platforms-and-aoe-services/artifactory/)) +- can be used for server and client JavaScript development (see [node.js](/languages-and-frameworks/node-js/) ) diff --git a/radar/2017-03-01/oro-platform.md b/radar/2017-03-01/oro-platform.md index 7d09fd8..0a3c76c 100644 --- a/radar/2017-03-01/oro-platform.md +++ b/radar/2017-03-01/oro-platform.md @@ -10,6 +10,6 @@ One of the central features is that entities, which are to be managed within the As with every framework or application, the general-purpose goals and abstraction comes with drawbacks: In fact, OroPlatform modifies and extends the common way of doing things in Symfony in several places, which makes the developer's life hard at times. Also, the UI and package managing are set in such a way that they are hard to extend or replace. The many additional abstraction layers can result in decreased performance. -On the other hand, OroPlatform gives you a good head start for prototyping and frees you from rebuilding common requirements - which makes it a relevant choice for business applications with the need to manage several entities in a backend. Also, projects such [Akeneo](/tools/akeneo.html) or OroCRM use OroPlatform with success. +On the other hand, OroPlatform gives you a good head start for prototyping and frees you from rebuilding common requirements - which makes it a relevant choice for business applications with the need to manage several entities in a backend. Also, projects such [Akeneo](/tools/akeneo/) or OroCRM use OroPlatform with success. Since the project is still young, the future development and improvements need to be watched. We classified the Framework as ***Assess***. diff --git a/radar/2017-03-01/php7-over-php5.md b/radar/2017-03-01/php7-over-php5.md index baa4e59..911352c 100644 --- a/radar/2017-03-01/php7-over-php5.md +++ b/radar/2017-03-01/php7-over-php5.md @@ -13,4 +13,4 @@ Here at AOE, we have numerous PHP projects, and we often kept it backwards-compa Now, PHP 5 has reached its end--of-life, and it is time to discontinue the backwards-compatibility in favor of better and more stable applications. Even though we can use the PHP 7 runtime while being PHP 5-compatible, it is not considered good practice anymore, as we can now rely on the PHP 7 features and use all of its advantages. -One of the major points PHP 7 supports is proper type hinting and return types (apart from PhpDocs), which makes [static analysis](/tools/phan.html) much easier and can improve the overall code quality significantly. +One of the major points PHP 7 supports is proper type hinting and return types (apart from PhpDocs), which makes [static analysis](/tools/phan/) much easier and can improve the overall code quality significantly. diff --git a/radar/2017-03-01/pin-external-dependencies.md b/radar/2017-03-01/pin-external-dependencies.md index 8973ae8..07b70d6 100644 --- a/radar/2017-03-01/pin-external-dependencies.md +++ b/radar/2017-03-01/pin-external-dependencies.md @@ -32,7 +32,7 @@ We suggest the following: dependent packages are used. * It's also suggested to use local or central caches for the retrieval of packages. (E.g. - [artifactory as composer and npm cache](/platforms-and-aoe-services/artifactory.html)) + [artifactory as composer and npm cache](/platforms-and-aoe-services/artifactory/)) For updating of dependencies define a process in the team. This can either be done on the dev-system or in a separate automated CI job - both resulting in diff --git a/radar/2017-03-01/pipeline-as-code.md b/radar/2017-03-01/pipeline-as-code.md index 50562c1..8532585 100644 --- a/radar/2017-03-01/pipeline-as-code.md +++ b/radar/2017-03-01/pipeline-as-code.md @@ -8,4 +8,4 @@ Continuous Integration and Delivery is a critical part of our development and de Being an important part of each project, the pipeline configuration should be managed as code and rolled out automatically - this also allows us to manage the pipeline itself applying the same standards that apply to application code. -While some teams started using Jenkins' [JobDSL plugin,](https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin) others explored the new [Jenkins Pipeline](https://jenkins.io/doc/book/pipeline/) - in both ways, the build artifacts should be published to an artifact repository such as [Artifactory.](/platforms-and-aoe-services/artifactory.html) +While some teams started using Jenkins' [JobDSL plugin,](https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin) others explored the new [Jenkins Pipeline](https://jenkins.io/doc/book/pipeline/) - in both ways, the build artifacts should be published to an artifact repository such as [Artifactory](/platforms-and-aoe-services/artifactory/). diff --git a/radar/2017-03-01/play-framework.md b/radar/2017-03-01/play-framework.md index d5aab07..86d0f7e 100644 --- a/radar/2017-03-01/play-framework.md +++ b/radar/2017-03-01/play-framework.md @@ -4,7 +4,7 @@ ring: adopt quadrant: languages-and-frameworks --- -The Play Framework is a lightweight (web)application framework for Java and [Scala](/languages-and-frameworks/scala-lang.html) programmers. +The Play Framework is a lightweight (web)application framework for Java and [Scala](/languages-and-frameworks/scala-lang/) programmers. A developer can choose from different modules to include necessary functionality such s accessing http resources, databases, and so on. As a consequence, the developer can choose, and is not distracted by or clobbered with irrelevant things. This approach is considered as minimalistic, but it is easy to include necessary functionality. diff --git a/radar/2017-03-01/postcss.md b/radar/2017-03-01/postcss.md index d7dda58..30a59d3 100644 --- a/radar/2017-03-01/postcss.md +++ b/radar/2017-03-01/postcss.md @@ -13,4 +13,4 @@ Sure, not all of them are useful, but the sheer number of plugins shows how easy In fact, it´s just a matter of writing a single JS function. Finally, PostCSS is very fast and easy to setup because it runs 100% in JavaScript. -Compared to [Sass](/languages-and-frameworks/sass.html) as a preprocessor, it feels much more powerful but at the same time less bloated with superfluous functionality because everything comes in its own little plugin +Compared to [Sass](/languages-and-frameworks/sass/) as a preprocessor, it feels much more powerful but at the same time less bloated with superfluous functionality because everything comes in its own little plugin diff --git a/radar/2017-03-01/puppet-environments.md b/radar/2017-03-01/puppet-environments.md index b1eea0a..462f765 100644 --- a/radar/2017-03-01/puppet-environments.md +++ b/radar/2017-03-01/puppet-environments.md @@ -9,7 +9,7 @@ Puppet Puppet is an Open Source configuration management tool. It is used by a wide range of different companies world-wide, e.g. the Wikimedia Foundation, Mozilla, Reddit, CERN, Dell, Rackspace, Twitter, the New York Stock Exchange, PayPal, Disney, Citrix Systems, Spotify, Oracle, the University of California Los Angeles, the University of North Texas, QVC, Intel, Google and others. -Puppet has been the basic tool to address Continuous Configuration Automation (CCA) in AOE's [Infrastructure as Code](/methods-and-patterns/infrastructure-as-code.html) strategy (IaC) for more than 4 years. +Puppet has been the basic tool to address Continuous Configuration Automation (CCA) in AOE's [Infrastructure as Code](/platforms-and-aoe-services/infrastructure-as-code/) strategy (IaC) for more than 4 years. Puppet Environments ------------------- diff --git a/radar/2017-03-01/rabbitmq.md b/radar/2017-03-01/rabbitmq.md index b8ba5f6..a85f333 100644 --- a/radar/2017-03-01/rabbitmq.md +++ b/radar/2017-03-01/rabbitmq.md @@ -6,8 +6,8 @@ quadrant: tools RabbitMQ is an Open Source message broker - implementing the Advanced Message Queuing Protocol (AMQP) protocol. It provides a reliable and scalable way to transport data between loosely coupled applications, using different EAI patterns such as the Publish & Subscriber pattern. AMQP supports direct and fan-out exchanges (broadcasts) as well as topics. Queuing mechanisms allow for robust architectures, mitigating the risks of application downtimes. Typically, a RabbitMQ server can easily buffer millions of messages. RabbitMQ supports JMS in addition to AMQP. It is not intended to use JMS for new systems, but it makes RabbitMQ useful for integrating legacy systems. -There are several alternative solutions to RabbitMQ, e. g. the free Apache ActiveMQ, which is integrated in [Anypoint platform](/tools/anypoint-platform.html). ActiveMQ implements a somewhat simpler routing concept than RabbitMQ, but offers more protocols. Commercial products in this area are offered by IBM (Websphere MQ), Fiorano and almost every vendor of ESB products. +There are several alternative solutions to RabbitMQ, e. g. the free Apache ActiveMQ, which is integrated in [Anypoint platform](/tools/anypoint-platform/). ActiveMQ implements a somewhat simpler routing concept than RabbitMQ, but offers more protocols. Commercial products in this area are offered by IBM (Websphere MQ), Fiorano and almost every vendor of ESB products. -We use RabbitMQ internally for transferring messages safely in our logging ecosystem between [Logstash](/platforms-and-aoe-services/elk-stack.html) proxies and servers using direct and fan-out exchanges for delivering messages to appropriate destinations. RabbitMQ is also used to asynchronously trigger Jenkins jobs from our SCMs to mitigate heavy load on the SCMs, usually caused by Jenkins polls for SCM changes. Additionally, some critical events for monitoring are using RabbitMQ for guaranteed notification. +We use RabbitMQ internally for transferring messages safely in our logging ecosystem between [Logstash](/platforms-and-aoe-services/elk-stack/) proxies and servers using direct and fan-out exchanges for delivering messages to appropriate destinations. RabbitMQ is also used to asynchronously trigger Jenkins jobs from our SCMs to mitigate heavy load on the SCMs, usually caused by Jenkins polls for SCM changes. Additionally, some critical events for monitoring are using RabbitMQ for guaranteed notification. -RabbitMQ is rated "Trial". It fits into our approach to build robust, [resilient systems](/methods-and-patterns/resilience-thinking.html) and use [asynchronous messages](/methods-and-patterns/decoupling-infrastructure-via-messaging.html) for loosely coupled communications between components. In practice, RabbitMQ proved to be stable and dealt well with service interruptions from failures and maintenance slots. A common pain point is RabbitMQ as a single point of failure disrupting the data flow in a system. This issue is currently approached by setting up a HA cluster for RabbitMQ. The outcome of this approach will clarify the extent of future usage of RabbitMQ in our systems. +RabbitMQ is rated "Trial". It fits into our approach to build robust, [resilient systems](/methods-and-patterns/resilience-thinking/) and use [asynchronous messages](/methods-and-patterns/decoupling-infrastructure-via-messaging/) for loosely coupled communications between components. In practice, RabbitMQ proved to be stable and dealt well with service interruptions from failures and maintenance slots. A common pain point is RabbitMQ as a single point of failure disrupting the data flow in a system. This issue is currently approached by setting up a HA cluster for RabbitMQ. The outcome of this approach will clarify the extent of future usage of RabbitMQ in our systems. diff --git a/radar/2017-03-01/raml.md b/radar/2017-03-01/raml.md index d1a69ae..377fa02 100644 --- a/radar/2017-03-01/raml.md +++ b/radar/2017-03-01/raml.md @@ -4,7 +4,7 @@ ring: adopt quadrant: tools --- -[RAML](http://raml.org/) (the RESTful API Modelling Language) is a YAML-based API specification language. It's now available in [version 1.0](https://github.com/raml-org/raml-spec/blob/master/versions/raml-10/raml-10.md#defining-types). The philosophy behind it is to [specify the API before implementation](/methods-and-patterns/api-first-design-approach.html). +[RAML](http://raml.org/) (the RESTful API Modelling Language) is a YAML-based API specification language. It's now available in [version 1.0](https://github.com/raml-org/raml-spec/blob/master/versions/raml-10/raml-10.md#defining-types). The philosophy behind it is to [specify the API before implementation](/methods-and-patterns/api-first-design-approach/). If you follow this philosophy, you can design your API and discuss it with your clients and team before implementing a single line of code. API consumers are able to implement against the API before it's really up and running. The [api-console](https://github.com/mulesoft/api-console) provides a beautiful online documentation with "try it" features for your raml definition. diff --git a/radar/2017-03-01/resilience-thinking.md b/radar/2017-03-01/resilience-thinking.md index 2a4ee2c..092599b 100644 --- a/radar/2017-03-01/resilience-thinking.md +++ b/radar/2017-03-01/resilience-thinking.md @@ -11,7 +11,7 @@ There are a lot of different resilience patterns and it is also a matter of the * Do not hide API calls or any other external communication in your application (for example with unnecessary abstraction) - instead make it explicit that an external communication happens - e.g. by using the Facade Pattern. On the one hand, this makes it obvious that a potential slow and error prone communication is going to happen, and it makes it easier to implement error handling. * Detect errors explicitly: Check the response message format and configure proper timeouts for external communication * Handle errors in a smart way: Show a nice error message to your customer or, even better, graceful degrade features - e.g. by showing some fallback text -* Use Message-based communication where useful ([Decoupling Infrastructure via Messaging](/methods-and-patterns/decoupling-infrastructure-via-messaging.html)) +* Use Message-based communication where useful ([Decoupling Infrastructure via Messaging](/methods-and-patterns/decoupling-infrastructure-via-messaging/)) * Use Circuit Breaker to Isolate errors and allow system to recover * Use short activation paths in your strategic architecture - so that there is only a minimal set of communications between your services required for certain features or business requests diff --git a/radar/2017-03-01/sass.md b/radar/2017-03-01/sass.md index 403a84c..685e993 100644 --- a/radar/2017-03-01/sass.md +++ b/radar/2017-03-01/sass.md @@ -14,7 +14,7 @@ Core features of Sass are: * Extends: CSS properties can be inherited * Sass files can be split into modules, which leads to smaller files and better file structures * Operators: Simple math calculations can be applied to CSS properties -* Easily to integrate in nodejs-environments and build tools such as [npm](/tools/npm.html), [Gulp](/tools/gulp.html) and [Grunt](/tools/grunt.html). +* Easily to integrate in nodejs-environments and build tools such as [npm](/tools/npm/), [Gulp](/tools/gulp/) and [Grunt](/tools/grunt/). Sass has been widely adopted for many years and has evolved to an industry-standard backed by an active community since 2006. diff --git a/radar/2017-03-01/settings-injection.md b/radar/2017-03-01/settings-injection.md index 9e4035a..6573432 100644 --- a/radar/2017-03-01/settings-injection.md +++ b/radar/2017-03-01/settings-injection.md @@ -6,6 +6,6 @@ quadrant: methods-and-patterns While deploying applications to an environment, the application typically needs to be configured for that specific environment. Typical settings include domain names, database credentials and the location of other dependent services such as cache backends, queues or session storages. -These settings should not be shipped with the build package. Instead, it's the environment - this build is being deployed to - that should expose these values to application. A common way to "inject" these values is by making them available as environment variables or dynamically creating configuration files for the application. You can achieve this pattern without special tools - but this concept of settings injection also works with tools such as [Consul](/tools/consul.html), [kubernetes](/platforms-and-aoe-services/kubernetes.html) (with configMaps and secrets) or [YAD](https://github.com/AOEpeople/YAD). +These settings should not be shipped with the build package. Instead, it's the environment - this build is being deployed to - that should expose these values to application. A common way to "inject" these values is by making them available as environment variables or dynamically creating configuration files for the application. You can achieve this pattern without special tools - but this concept of settings injection also works with tools such as [Consul](/tools/consul/), [kubernetes](/platforms-and-aoe-services/kubernetes/) (with configMaps and secrets) or [YAD](https://github.com/AOEpeople/YAD). In this manner, the build package can be independent of the environment it's being deployed to - making it easier to follow the "Build once, deploy often" CI/CD principle. diff --git a/radar/2017-03-01/spring-rest-docs.md b/radar/2017-03-01/spring-rest-docs.md index 36bac02..c6a8d23 100644 --- a/radar/2017-03-01/spring-rest-docs.md +++ b/radar/2017-03-01/spring-rest-docs.md @@ -4,8 +4,8 @@ ring: assess quadrant: tools --- -[Spring REST Docs](https://projects.spring.io/spring-restdocs/) auto generates [Asciidoctor](http://asciidoctor.org/) snippets with the help of [Spring MVC Test](http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle#spring-mvc-test-framework) or [RestAssured](/tools/rest-assured.html). +[Spring REST Docs](https://projects.spring.io/spring-restdocs/) auto generates [Asciidoctor](http://asciidoctor.org/) snippets with the help of [Spring MVC Test](http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle#spring-mvc-test-framework) or [RestAssured](/tools/rest-assured/). So you can be sure that your tests are inline with the documentation. At AOE, we use [Spring REST Docs](https://projects.spring.io/spring-restdocs/) to document our Rest Services and Hal Resources. -We also use it to auto generate [WireMock](/tools/wiremock.html) Stubs, so the consumer of the service can test against the exact API of the service. +We also use it to auto generate [WireMock](/tools/wiremock/) Stubs, so the consumer of the service can test against the exact API of the service. diff --git a/radar/2017-03-01/strategic-domain-driven-design.md b/radar/2017-03-01/strategic-domain-driven-design.md index 1622107..cfd6c0f 100644 --- a/radar/2017-03-01/strategic-domain-driven-design.md +++ b/radar/2017-03-01/strategic-domain-driven-design.md @@ -10,9 +10,9 @@ Design of distributed applications need to be done wisely. Strategic Domain Driv Domain driven design is a well-known pattern family and has been established at AOE for quite some time now. Unlike Domain Driven Design, which focuses on the tactical design in an application, strategic domain driven design is an approach that is very helpful for the high-level strategic design of an application and distributed software architecture. It is a pattern family focused on using and defining Bounded Context and thinking explicitly of the different relationship patterns and the required "translation" of similar "concepts" between the bounded contexts. It is helpful to argue and find a good strategic architecture in alignment with the requirements, the domain and by considering Conway's Law. -A context map and a common conceptional core help to understand and improve the overall strategic picture. Especially with the [Microservice](/methods-and-patterns/microservices.html) approach, it is important to define and connect services following the low coupling - high cohesion principles by idendifying fitting bounded contexts. +A context map and a common conceptional core help to understand and improve the overall strategic picture. Especially with the [Microservice](/methods-and-patterns/microservices/) approach, it is important to define and connect services following the low coupling - high cohesion principles by idendifying fitting bounded contexts. The following chart gives an overview of possible relationships between bounded contexts: ![strategic-domain-driven-design-relationships](/images/strategic-domain-driven-design-relationships.png) -While we have found that this approach is especially useful in designing distributed systems and applications with [microservices](/methods-and-patterns/microservices.html), we have also extended this approach to provide guidelines for general enterprise architectures. \ No newline at end of file +While we have found that this approach is especially useful in designing distributed systems and applications with [microservices](/methods-and-patterns/microservices/), we have also extended this approach to provide guidelines for general enterprise architectures. \ No newline at end of file diff --git a/radar/2017-03-01/typescript.md b/radar/2017-03-01/typescript.md index 79ed10d..e7c5293 100644 --- a/radar/2017-03-01/typescript.md +++ b/radar/2017-03-01/typescript.md @@ -16,6 +16,6 @@ TypeScript continues to be actively developed by Microsoft and is well-Integrate The excellent structure and the possibilities for extension make it a good choice to consider for larger JavaScript projects. -Typescript was the choice for [Angular](/languages-and-frameworks/angular.html) and one can assume that it will get more traction with the success of Angular in the future. +Typescript was the choice for [Angular](/languages-and-frameworks/angular/) and one can assume that it will get more traction with the success of Angular in the future. There are also projects that support Typescript „code execution“ on the server such as [ts-node](https://www.npmjs.com/package/ts-node). diff --git a/radar/2017-03-01/webpack.md b/radar/2017-03-01/webpack.md index 59a7937..da61616 100644 --- a/radar/2017-03-01/webpack.md +++ b/radar/2017-03-01/webpack.md @@ -4,7 +4,7 @@ ring: trial quadrant: tools --- -[Webpack](https://webpack.js.org/) is a web bundler for JavaScript applications. Instead of writing scripts to build and bundle your app like you would with [Gulp](/tools/gulp.html), you just define what files you want to load into your bundle. +[Webpack](https://webpack.js.org/) is a web bundler for JavaScript applications. Instead of writing scripts to build and bundle your app like you would with [Gulp](/tools/gulp/), you just define what files you want to load into your bundle. In the following example, we define that JavaScript files should be handled by babel-loader, excluding the files from node_modules. The logic behind the process comes from the [loader](https://webpack.js.org/concepts/loaders/). You can find the right loader in [npm](https://www.npmjs.com/search?q=loader%20webpack&page=1&ranking=optimal). diff --git a/radar/2017-03-01/wiremock.md b/radar/2017-03-01/wiremock.md index b066249..7e5a4da 100644 --- a/radar/2017-03-01/wiremock.md +++ b/radar/2017-03-01/wiremock.md @@ -10,6 +10,6 @@ At its core, it is a web server that can be prepared to serve canned responses t It can be used as a library by any JVM application, or run as a standalone process either on the same host as the system under test or a remote server. All of WireMock's features are accessible via its REST (JSON) interface and its Java API. Additionally, the mock server can be configured via JSON files. -At AOE, we use WireMock as a standalone server to mock APIs that are outside our system context to get a stable environment for testing and rapid feedback. Besides the decoupled test and development advantages, the mocked APIs can also be used in contract-based tests. We also use embedded WireMock in functional tests to stub external services. The explicit test of faults are especially helpful in building and testing the [resilience of your application](/methods-and-patterns/resilience-thinking.html). +At AOE, we use WireMock as a standalone server to mock APIs that are outside our system context to get a stable environment for testing and rapid feedback. Besides the decoupled test and development advantages, the mocked APIs can also be used in contract-based tests. We also use embedded WireMock in functional tests to stub external services. The explicit test of faults are especially helpful in building and testing the [resilience of your application](/methods-and-patterns/resilience-thinking/). Because of the features such as flexible deployment, powerful request matching and record/payback interactions, as well as the fact that the server runs stable in our project environments, we classify WireMock as *trial*. \ No newline at end of file diff --git a/radar/2018-03-01/akka-streams.md b/radar/2018-03-01/akka-streams.md index 9069ec1..ac0c3b1 100644 --- a/radar/2018-03-01/akka-streams.md +++ b/radar/2018-03-01/akka-streams.md @@ -16,5 +16,5 @@ It handles things such as message resending in failure cases and preventing mess Our first trials with Akka Streams were promising but we haven't yet implemented complex services with it. -We will continue looking into it together with the [Alpakka](/languages-and-frameworks/alpakka.html) Connectors for integration +We will continue looking into it together with the [Alpakka](/languages-and-frameworks/alpakka/) Connectors for integration work. diff --git a/radar/2018-03-01/alpakka.md b/radar/2018-03-01/alpakka.md index 5b1c0f9..5e8cc66 100644 --- a/radar/2018-03-01/alpakka.md +++ b/radar/2018-03-01/alpakka.md @@ -4,7 +4,7 @@ ring: assess quadrant: languages-and-frameworks --- -When using [Akka Streams](/languages-and-frameworks/akka-streams.html) to build reactive data transformation services you usually need to connect to several services such as FTP, S3 buckets, AMQP brokers or different databases. +When using [Akka Streams](/languages-and-frameworks/akka-streams/) to build reactive data transformation services you usually need to connect to several services such as FTP, S3 buckets, AMQP brokers or different databases. [Alpakka](https://developer.lightbend.com/docs/alpakka/current/) provides integration building blocks for Akka Streams to access these services in a reactive fashion and contains transformations for working with XML, CSV or JSON structured data. diff --git a/radar/2018-03-01/crc.md b/radar/2018-03-01/crc.md index fd4f118..5e514d8 100644 --- a/radar/2018-03-01/crc.md +++ b/radar/2018-03-01/crc.md @@ -29,5 +29,5 @@ This is how we often conduct a CRC Session: * Closing: * We are often not too enthusiastic about adding a list of "collaborators" to the cards, since the sequence explains this very well. * So just take a picture and document the result somewhere, so that you can review the status for the next CRC session. - * Maybe some decisions are worth being documented in your [Architecture decision records](/methods-and-patterns/adr.html) + * Maybe some decisions are worth being documented in your [Architecture decision records](/methods-and-patterns/adr/) \ No newline at end of file diff --git a/radar/2018-03-01/kubernetes.md b/radar/2018-03-01/kubernetes.md index ab3edce..1db6e9a 100644 --- a/radar/2018-03-01/kubernetes.md +++ b/radar/2018-03-01/kubernetes.md @@ -9,5 +9,5 @@ Kubernetes has developed into the quasi-standard for container orchestration: Ne We are running several production systems with Kubernetes and we are using it in concepts such as: * "secrets" and "configmaps" to manage configurations for the applications. By updating these resources with an automated configuration pipeline you have a great method for configuration management. * Autoscaling of Kubernetes nodes and the usage of "horizontal pod scaling" inside Kubernetes allows elastic scaling - * The support of managing permissions with OAuth allows you to secure Kubernetes with [Keycloak](/tools/keycloak.html) (SSO) + * The support of managing permissions with OAuth allows you to secure Kubernetes with [Keycloak](/tools/keycloak/) (SSO) * Kubernetes extensibility and API can be used for automation and customization. There is a growing ecosystem around extensions, which adds additional features. diff --git a/radar/2018-03-01/pact.md b/radar/2018-03-01/pact.md index 104907d..41796c6 100644 --- a/radar/2018-03-01/pact.md +++ b/radar/2018-03-01/pact.md @@ -11,6 +11,6 @@ Consumer Driven Contract testing is a pattern for testing interfaces/boundaries It allows "consumers" to run tests against a defined Mock and record the defined interactions (=PACT). It puts "providers" in the position to run the PACT tests inside their Continuous Integration Pipelines, so that the provider knows if he might break any consumers. -This approach makes sense in organisations where teams collaborate more closely (See [Strategic Domain Driven Design](/methods-and-patterns/strategic-domain-driven-design.html) ), e.g. to build [Microservice oriented architectures](/methods-and-patterns/microservices.html) +This approach makes sense in organisations where teams collaborate more closely (See [Strategic Domain Driven Design](/methods-and-patterns/strategic-domain-driven-design/) ), e.g. to build [Microservice oriented architectures](/methods-and-patterns/microservices/) Consumer Driven Contract Testing and how it can be conducted with PACT is documented very nicely on the official PACT website: https://docs.pact.io/. diff --git a/radar/2018-03-01/reactive-programming.md b/radar/2018-03-01/reactive-programming.md index ffc927e..d294af1 100644 --- a/radar/2018-03-01/reactive-programming.md +++ b/radar/2018-03-01/reactive-programming.md @@ -15,4 +15,4 @@ There are various descriptions of what Reactive Programming actually is - at the Under the term "Reactive Programming", we summarize the principles and implementations that underlie [ReactiveX](http://reactivex.io/) and the [Reactive Manifesto](https://www.reactivemanifesto.org/). "Reactive Programming" is employed in many of our services – frontend and backend – but not always as an explicitly chosen pattern. -As different platforms have different means to tackle this style of programming, we choose to include "Reactive Programming" as a general Method and Patterns Item in addition to concrete libraries and APIs such as [Rx.JS](languages-and-frameworks/rxjs.html) or [Akka Streams](/languages-and-frameworks/akka-streams.html) to highlight the importance of the approach in general. +As different platforms have different means to tackle this style of programming, we choose to include "Reactive Programming" as a general Method and Patterns Item in addition to concrete libraries and APIs such as [Rx.JS](/languages-and-frameworks/rxjs/) or [Akka Streams](/languages-and-frameworks/akka-streams/) to highlight the importance of the approach in general. diff --git a/radar/2018-03-01/terraform.md b/radar/2018-03-01/terraform.md index c4200f8..8c16d74 100644 --- a/radar/2018-03-01/terraform.md +++ b/radar/2018-03-01/terraform.md @@ -8,4 +8,4 @@ For the infrastructure of our OM3 projects we run multiple Kubernetes clusters, Terraform allows us to easily manage our infrastructure, from AWS EC2 instances to RabbitMQ message queues. Also, the Kops installer for Kubernetes on AWS uses Terraform as its main building brick, and we can trigger Kops via Terraform. -We bring terraform together with [Helm](/tools/helm.html) to manage similar parts of the infrastructure, for example a shared file with domain name to application mappings allows us to provision Route 53 DNS entries via Terraform and then roll out Kubernetes Ingress definitions with the appropriate hostname to service mapping via Helm. +We bring terraform together with [Helm](/platforms-and-aoe-services/helm/) to manage similar parts of the infrastructure, for example a shared file with domain name to application mappings allows us to provision Route 53 DNS entries via Terraform and then roll out Kubernetes Ingress definitions with the appropriate hostname to service mapping via Helm. diff --git a/radar/2019-11-01/anypoint-platform.md b/radar/2019-11-01/anypoint-platform.md index 88baa25..6773848 100644 --- a/radar/2019-11-01/anypoint-platform.md +++ b/radar/2019-11-01/anypoint-platform.md @@ -5,4 +5,4 @@ quadrant: tools featured: false --- -Recently our teams migrated some project from Anypoint to ["Apache Camel"](/tools/apache-camel.html) or use ["Alpakka"](/tools/alpakka.html) for integration work. \ No newline at end of file +Recently our teams migrated some project from Anypoint to ["Apache Camel"](/languages-and-frameworks/apache-camel/) or use ["Alpakka"](/languages-and-frameworks/alpakka/) for integration work. \ No newline at end of file diff --git a/radar/2019-11-01/container-based-builds.md b/radar/2019-11-01/container-based-builds.md index e29ec35..ef8a031 100644 --- a/radar/2019-11-01/container-based-builds.md +++ b/radar/2019-11-01/container-based-builds.md @@ -4,4 +4,4 @@ ring: adopt quadrant: methods-and-patterns --- -Updated to "adopt". Container based builds has getting to the de facto standard for our pipelines in [GitLab](/tools/gitlab.html) or other CI Tools. \ No newline at end of file +Updated to "adopt". Container based builds has getting to the de facto standard for our pipelines in [GitLab](/tools/gitlab/) or other CI Tools. \ No newline at end of file diff --git a/radar/2019-11-01/distributed-tracing.md b/radar/2019-11-01/distributed-tracing.md index c291b57..d931f10 100644 --- a/radar/2019-11-01/distributed-tracing.md +++ b/radar/2019-11-01/distributed-tracing.md @@ -8,4 +8,4 @@ tags: [devops] Distributed Tracing creates visibility over processes spanning multiple applications. In a microservice world where a request or operation involves multiple applications it is helpful to have an overview of what system is involved, at what point. Also, visibility of communicated data and errors helps to quickly identify issues in a microservice environment. -Our tool of choice is [Jaeger](/platforms-and-aoe-services/jaeger.html) with [B3 Propagation](https://github.com/openzipkin/b3-propagation). +Our tool of choice is [Jaeger](/platforms-and-aoe-services/jaeger/) with [B3 Propagation](https://github.com/openzipkin/b3-propagation). diff --git a/radar/2019-11-01/flamingo.md b/radar/2019-11-01/flamingo.md index 4ca7131..3b0ed68 100644 --- a/radar/2019-11-01/flamingo.md +++ b/radar/2019-11-01/flamingo.md @@ -32,7 +32,7 @@ Flamingo has a clean architecture with clear dependencies in mind and offers a t * GraphQL support and therefore support to build nice SPA and PWAs on top of it * Resilience and Caching for external APIs calls. -Flamingo itself does not contain ORM Mapper or libraries - instead it emphasizes ["ports and adapters"](/methods-and-patterns/ports-and-adapters.html) architecture - so that you have a technology free (domain) model and any possible (and replaceable) persistence behind it. +Flamingo itself does not contain ORM Mapper or libraries - instead it emphasizes ["ports and adapters"](/methods-and-patterns/ports-and-adapters/) architecture - so that you have a technology free (domain) model and any possible (and replaceable) persistence behind it. That makes Flamingo useful to build microservices and applications - especially to build "frontends" or portals that require interaction with other (micro) services in a distributed architecture. When sticking to the architectural recommendation, you can build modular applications with replaceable adapters that gives you independent testability. diff --git a/radar/2019-11-01/gitlab.md b/radar/2019-11-01/gitlab.md index 605f535..cd07be9 100644 --- a/radar/2019-11-01/gitlab.md +++ b/radar/2019-11-01/gitlab.md @@ -5,4 +5,4 @@ quadrant: tools --- Moved to "adopt": GitLab has proven to be a very useful tool for code and the collaboration around it. -With [GitLab CI](/tools/gitlab-ci.html) there is also a powerful tool to automate continuous integration and delivery. +With [GitLab CI](/tools/gitlab-ci/) there is also a powerful tool to automate continuous integration and delivery. diff --git a/radar/2019-11-01/graphql.md b/radar/2019-11-01/graphql.md index 78e9fba..f55a45d 100644 --- a/radar/2019-11-01/graphql.md +++ b/radar/2019-11-01/graphql.md @@ -18,8 +18,8 @@ Key advantages are: - the client (browser) controls what data should be sent (data reduction) - with one request you can fetch "all" required data -Client side integration can be achieved using the [Apollo Client Framework](/tools/apollo-client.html) which easily -integrates into [React.js](/languages-and-frameworks/react.html) based frontends. +Client side integration can be achieved using the [Apollo Client Framework](/tools/apollo-client/) which easily +integrates into [React.js](/languages-and-frameworks/react/) based frontends. The Flamingo framework [offers support for GraphQL](https://docs.flamingo.me/3.%20Flamingo%20Modules/graphql.html) while Flamingo Commerce provides a full-featured GraphQL API for e-commerce: diff --git a/radar/2019-11-01/jaeger.md b/radar/2019-11-01/jaeger.md index 895f10f..ddd2423 100644 --- a/radar/2019-11-01/jaeger.md +++ b/radar/2019-11-01/jaeger.md @@ -4,7 +4,7 @@ ring: trial quadrant: platforms-and-aoe-services --- -[Jaeger](https://www.jaegertracing.io/) is a tool for [Distributed Tracing](/platforms-and-aoe-services/distributed-tracing.html). +[Jaeger](https://www.jaegertracing.io/) is a tool for [Distributed Tracing](/platforms-and-aoe-services/distributed-tracing/). Developed at Uber and inspired by Dapper and OpenZipkin it grew into an [Cloud Native Computing Foundation](https://www.cncf.io/) project. Jaeger is a great tool for troubleshooting distributed systems, such as microservice architectures. diff --git a/radar/2019-11-01/packer.md b/radar/2019-11-01/packer.md index e64c0c0..2e2e291 100644 --- a/radar/2019-11-01/packer.md +++ b/radar/2019-11-01/packer.md @@ -13,4 +13,4 @@ Another benefit is, that machine images can be tested to verify if they are work Packer supports multiple cloud providers like AWS, GCP, Digital Ocean etc. Machine images are important for modern deployment pipelines and fast ramp of new infrastructure. -We are using Packer to build so-called "Golden images" that are used in our [Infrastructure as Code](/methods-and-patterns/infrastructure-as-code.html) based provisionings. +We are using Packer to build so-called "Golden images" that are used in our [Infrastructure as Code](/platforms-and-aoe-services/infrastructure-as-code/) based provisionings. diff --git a/radar/2019-11-01/raml.md b/radar/2019-11-01/raml.md index a165292..d1948d0 100644 --- a/radar/2019-11-01/raml.md +++ b/radar/2019-11-01/raml.md @@ -4,6 +4,6 @@ ring: hold quadrant: languages-and-frameworks --- -Since the RAML project has decided to [join](https://blogs.mulesoft.com/dev/api-dev/open-api-raml-better-together/) the OpenAPI initiative and the RAML ecosystem lacks further development and additional tools, we decided to use and recommend using ["OpenAPI specification (OAS)"](/tools/open-api.html) as description standard instead. +Since the RAML project has decided to [join](https://blogs.mulesoft.com/dev/api-dev/open-api-raml-better-together/) the OpenAPI initiative and the RAML ecosystem lacks further development and additional tools, we decided to use and recommend using ["OpenAPI specification (OAS)"](/tools/open-api/) as description standard instead. RAML still provides advantages in modeling an API through it's more expressive modeling language and can produce OAS \ No newline at end of file diff --git a/radar/2019-11-01/zero-trust.md b/radar/2019-11-01/zero-trust.md index 5429e0d..823c632 100644 --- a/radar/2019-11-01/zero-trust.md +++ b/radar/2019-11-01/zero-trust.md @@ -42,7 +42,7 @@ It involves many **areas and aspects**, including: ## Implementations In 2009 Google implemented a zero trust architecture referred to as [BeyondCorp](https://cloud.google.com/beyondcorp). It utilizes OAuth and OpenID standards for implementing Authn and Authz, and has influenced the development of modern Zero Trust architectures. -Typical implementations involve using standards and tools for IAM and SSO, such as [Keycloak](/tools/keycloak.html). +Typical implementations involve using standards and tools for IAM and SSO, such as [Keycloak](/tools/keycloak/). ## Summary While network segments and VPN connections may still be relevant in specific areas, AOE is increasingly implementing a Zero Trust approach in all solutions, components, and services. diff --git a/radar/2021-07-01/cockpit.md b/radar/2021-07-01/cockpit.md index fb03a25..c08ca6f 100644 --- a/radar/2021-07-01/cockpit.md +++ b/radar/2021-07-01/cockpit.md @@ -5,4 +5,4 @@ quadrant: tools featured: false --- -We decided to put this CMS on hold due to other - more adopted - alternatives like [Strapi](/tools/strapi.html). \ No newline at end of file +We decided to put this CMS on hold due to other - more adopted - alternatives like [Strapi](/tools/strapi/). \ No newline at end of file diff --git a/radar/2021-07-01/conventionalcommits.md b/radar/2021-07-01/conventionalcommits.md index 3a615a9..6d914f0 100644 --- a/radar/2021-07-01/conventionalcommits.md +++ b/radar/2021-07-01/conventionalcommits.md @@ -7,7 +7,7 @@ tags: [coding, quality assurance, ci/cd] The Conventional Commits specification is a lightweight convention on top of commit messages. It provides a small set of rules for writing commit messages and therefore creating an explicit commit history. -The convention dovetails with [SemVer](/methods-and-patterns/semver2.html), by describing the features, fixes, and breaking changes made in commit messages. +The convention dovetails with [SemVer](/methods-and-patterns/semver2/), by describing the features, fixes, and breaking changes made in commit messages. The specification contains only 16 items that are easy to follow. The predefined structure allows everyone in the team to get a better overview of what the commit messages relates to and what part of the code a change has to do with. Some benefits of using these specifications include: the ability to automatically generate changelogs, the ability to determine a semantic version bump (based on the types of commits landed) and being able to communicate the nature of changes to teammates and stakeholders. diff --git a/radar/2021-07-01/diagrams-as-code.md b/radar/2021-07-01/diagrams-as-code.md index fd8d244..73d8d5a 100644 --- a/radar/2021-07-01/diagrams-as-code.md +++ b/radar/2021-07-01/diagrams-as-code.md @@ -9,5 +9,5 @@ Documenting concepts and software architecture as diagrams using code offers gre Having documentation and diagrams treated as code and checked-in into version control increases transparency, collaboration as well as productivity. The textual representation of diagrams is easy to write and read. Generation of graphical representations as SVG or PNG images is also easy with the associated tools. -We make heavy use of [PlantUML](/tools/plant-uml.html) combined with [Asciidoc](/tools/asciidoc.html) and tools like [AsciiDoctor Diagram](https://asciidoctor.org/docs/asciidoctor-diagram/) to include and inline PlantUML diagrams into documentations. +We make heavy use of [PlantUML](/tools/plant-uml/) combined with [Asciidoc](/tools/asciidoc/) and tools like [AsciiDoctor Diagram](https://asciidoctor.org/docs/asciidoctor-diagram/) to include and inline PlantUML diagrams into documentations. The latter allows a variety of other diagram formats which can be easily mixed and matched. diff --git a/radar/2021-07-01/docker.md b/radar/2021-07-01/docker.md index 7a056ce..49065bb 100644 --- a/radar/2021-07-01/docker.md +++ b/radar/2021-07-01/docker.md @@ -11,5 +11,5 @@ But Docker is also a complete production platform, where the capability to build At the same time numerous alternate runtimes for containers – like containerd and podman – as well as image builders – like Kaniko and Buildah – have evolved during the last years. Thanks to the standards established by the Open Container Initiative these tools are mostly interchangeable for the purposes of building and running containers. -To be more distinct, we now recommend using [Containers and Runtimes as specified by the Open Container Initiative](/platforms-and-aoe-services/oci-container.html). +To be more distinct, we now recommend using [Containers and Runtimes as specified by the Open Container Initiative](/platforms-and-aoe-services/oci-container/). Docker is one of many tools to achieve that. diff --git a/radar/2021-07-01/drupal.md b/radar/2021-07-01/drupal.md index 277bc93..cbdd771 100644 --- a/radar/2021-07-01/drupal.md +++ b/radar/2021-07-01/drupal.md @@ -10,4 +10,4 @@ It has a huge community, so it's no wonder it's among the top 10 CMS worldwide i At AOE we consume Drupal mainly headless via JSON API. We appreciate its large feature set and mature plugin system as well as the general ecosystem. -In addition, the extensive documentation and setup with [DDEV](/tools/ddev.html) make it easy to get started. \ No newline at end of file +In addition, the extensive documentation and setup with [DDEV](/tools/ddev/) make it easy to get started. \ No newline at end of file diff --git a/radar/2021-07-01/eks.md b/radar/2021-07-01/eks.md index af3936b..dea36ee 100644 --- a/radar/2021-07-01/eks.md +++ b/radar/2021-07-01/eks.md @@ -9,8 +9,8 @@ tags: [devops] Amazon EKS runs Kubernetes control plane instances across multiple Availability Zones to ensure high availability. It also provides automated version upgrades and patching for them. -Amazon EKS is fully supported by [Terraform](https://www.aoe.com/techradar/platforms-and-aoe-services/terraform.html) which brings the advantage that its configuration is written in code, -which fulfils the [infrastructure as code](https://www.aoe.com/techradar/platforms-and-aoe-services/infrastructure-as-code.html) philosophy. +Amazon EKS is fully supported by [Terraform](/platforms-and-aoe-services/terraform/) which brings the advantage that its configuration is written in code, +which fulfils the [infrastructure as code](/platforms-and-aoe-services/infrastructure-as-code/) philosophy. Amazon has also implemented important (security) features to their service to ensure that Amazon EKS is well integrated into the broader AWS landscape. Kubernetes version upgrades and security patches are provided in a reliable schedule and with proper documentation. Alongside with the managed service, Amazons also provides its own [EKS distribution](https://aws.amazon.com/de/blogs/opensource/introducing-amazon-eks-distro/) which closes the gap for on-premise installations. diff --git a/radar/2021-07-01/kafka.md b/radar/2021-07-01/kafka.md index 063cccf..ca33aa8 100644 --- a/radar/2021-07-01/kafka.md +++ b/radar/2021-07-01/kafka.md @@ -7,6 +7,6 @@ featured: false "Apache Kafka is an open-source distributed event streaming platform used by thousands of companies for high-performance data pipelines, streaming analytics, data integration, and mission-critical applications." (See http://kafka.apache.org/) -In comparison with other messaging solutions (such as [RabbitMQ](/tools/rabbitmq.html) - Apacha Kafka persist the messages (instead of routing them to subscribers). It is written in Scala and Java, and follows the idea of a “distributed log” where messages are appended to the end (like in a log) - and that log is persisted to disk. Clients can choose where they begin reading from that log - often Kafka Streams is used for this. +In comparison with other messaging solutions (such as [RabbitMQ](/tools/rabbitmq/) - Apacha Kafka persist the messages (instead of routing them to subscribers). It is written in Scala and Java, and follows the idea of a “distributed log” where messages are appended to the end (like in a log) - and that log is persisted to disk. Clients can choose where they begin reading from that log - often Kafka Streams is used for this. We are using Kafka in data heavy projects - for example in data analytics use cases. diff --git a/radar/2021-07-01/nx.md b/radar/2021-07-01/nx.md index 4d1bd43..755b178 100644 --- a/radar/2021-07-01/nx.md +++ b/radar/2021-07-01/nx.md @@ -8,7 +8,7 @@ featured: true [Nx](https://nx.dev/) is a suite of powerful, extensible dev tools to help you architect, test, and build at any scale. It is mainly applicable in the environment of React, Angular and Node.js and tries to simplify and streamline the work in a mono repo. -At AOE, we are currently taking our first steps with NX in a mono repo that is home to both our React and Next.js based frontend and our [Go](/languages-and-frameworks/go-lang.html) / [Flamingo](/languages-and-frameworks/flamingo.html) based backend. +At AOE, we are currently taking our first steps with NX in a mono repo that is home to both our React and Next.js based frontend and our [Go](/languages-and-frameworks/go-lang/) / [Flamingo](/languages-and-frameworks/flamingo/) based backend. The integration with the Node.js components (React, Next.js, Cypress) works smoothly and brings the expected benefits such as faster build times through intelligent caching. Support for Go is currently only rudimentary, which is why NX still has to prove itself in this area. diff --git a/radar/2021-07-01/oci-container.md b/radar/2021-07-01/oci-container.md index bab2fb7..95215ac 100644 --- a/radar/2021-07-01/oci-container.md +++ b/radar/2021-07-01/oci-container.md @@ -13,6 +13,6 @@ In a DevOps environment, this helps a lot as we can run the exact same software In a CI environment building the containers allows us to package and test the whole environment instead of different software components on different runtimes in a much more stable way. -Backed by services such as [Kubernetes](/platforms-and-aoe-services/kubernetes.html) and [Helm](/platforms-and-aoe-services/helm.html), we can deploy containers on a flexible infrastructure and enable our developers to test their software more easily in different environments. +Backed by services such as [Kubernetes](/platforms-and-aoe-services/kubernetes/) and [Helm](/platforms-and-aoe-services/helm/), we can deploy containers on a flexible infrastructure and enable our developers to test their software more easily in different environments. Here at AOE, we use containers in different projects to become more flexible and faster, which increases our focus on development of even better and more stable software. diff --git a/radar/2021-07-01/prometheus.md b/radar/2021-07-01/prometheus.md index 6220cd3..503a2a9 100644 --- a/radar/2021-07-01/prometheus.md +++ b/radar/2021-07-01/prometheus.md @@ -12,7 +12,7 @@ Compared to other monitoring systems it stands out in its simple, still powerful Prometheus integrates very well with Grafana which is our tool of choice for dashboard visualization. Through the [Prometheus Operator](https://github.com/prometheus-operator/prometheus-operator) project, the monitoring system can be configured through Kubernetes custom resource definitions. -These can be shipped by development teams alongside with their application deployments and allow [sharing responsibility](https://www.aoe.com/techradar/methods-and-patterns/shared-responsibility.html) for monitoring tasks between operations and engineering teams with a clear interface. +These can be shipped by development teams alongside with their application deployments and allow [sharing responsibility](/methods-and-patterns/shared-responsibility/) for monitoring tasks between operations and engineering teams with a clear interface. With [Cortex](https://cortexmetrics.io/) and [Thanos](https://thanos.io/) the Prometheus-ecosystem knows two well-settled solutions for high-availability of the underlying time series database and with [Amazon Managed Services for Prometheus](https://aws.amazon.com/en/prometheus/) there's also a SaaS-Solution available. diff --git a/radar/2021-07-01/state-management-pattern.md b/radar/2021-07-01/state-management-pattern.md index 3074bb9..707b675 100644 --- a/radar/2021-07-01/state-management-pattern.md +++ b/radar/2021-07-01/state-management-pattern.md @@ -6,11 +6,11 @@ tags: [architecture, coding] --- State Management is a design pattern with the goal of properly sharing state data across components and separating domain representation from state management. -This pattern is applied by many popular web frameworks such as [Vuex](/languages-and-frameworks/vuex.html), [Redux](/languages-and-frameworks/redux.html) or [Flux](/methods-and-patterns/flux.html). +This pattern is applied by many popular web frameworks such as [Vuex](/languages-and-frameworks/vuex/), [Redux](/languages-and-frameworks/redux/) or [Flux](/methods-and-patterns/flux/). -Especially in [reactive](/methods-and-patterns/reactive-programming.html) systems, this pattern helps to solve the task of maintaining decoupled, stateless components with immutable data. +Especially in [reactive](/methods-and-patterns/reactive-programming/) systems, this pattern helps to solve the task of maintaining decoupled, stateless components with immutable data. The ways of implementing state management differs and depends on the specific requirements of the application at hand. -For distributed backend systems one might want to utilize [Akka's](/languages-and-frameworks/akka.html) cluster sharding module to elastically manage domain object states. +For distributed backend systems one might want to utilize [Akka's](/languages-and-frameworks/akka/) cluster sharding module to elastically manage domain object states. -We use the various state management patterns across most [Vue](/languages-and-frameworks/vue.html) and [React](/languages-and-frameworks/react.html) projects that warrant them. +We use the various state management patterns across most [Vue](/languages-and-frameworks/vue/) and [React](/languages-and-frameworks/react/) projects that warrant them. diff --git a/radar/2021-07-01/strapi.md b/radar/2021-07-01/strapi.md index f3e259a..6854c94 100644 --- a/radar/2021-07-01/strapi.md +++ b/radar/2021-07-01/strapi.md @@ -8,8 +8,8 @@ tags: [frontend] Strapi is a headless CMS built with Javascript on Node.js. Its data-centered approach offers great flexibility for many use cases by integrating with the available APIs. -Strapi's API comes in a RESTful and [GraphQL](/methods-and-patterns/graphql.html) variant. -Both perfectly support the [API-first design approach](/methods-and-patterns/api-first-design-approach.html). +Strapi's API comes in a RESTful and [GraphQL](/methods-and-patterns/graphql/) variant. +Both perfectly support the [API-first design approach](/methods-and-patterns/api-first-design-approach/). Ever since the stable release version 3.0.0 from mid-2020, the CMS reached market maturity and offers a good choice for scalable headless CMSs. As of the 3.6 release in April 2021, Strapi features [full internationalization support](https://strapi.io/blog/announcing-content-internationalization-v3-6), making it a viable candidate to be evaluated toe to toe with solutions like Drupal. diff --git a/radar/2022-03-28/gitlab-ci.md b/radar/2022-03-28/gitlab-ci.md index 185a480..83ab0b1 100644 --- a/radar/2022-03-28/gitlab-ci.md +++ b/radar/2022-03-28/gitlab-ci.md @@ -5,4 +5,4 @@ quadrant: tools featured: false --- -We merged "GitLab CI" and [GitLab](https://www.aoe.com/techradar/tools/gitlab.html) +We merged "GitLab CI" and [GitLab](/tools/gitlab/) diff --git a/radar/2022-03-28/monorepo.md b/radar/2022-03-28/monorepo.md index 6657a88..4a9433f 100644 --- a/radar/2022-03-28/monorepo.md +++ b/radar/2022-03-28/monorepo.md @@ -9,7 +9,7 @@ tags: [coding] A monorepo is a single repository containing multiple projects and shared libraries with their relationships. At AOE, we are using a monorepo that is home to both our React and Next.js based frontends and -our [Go](/languages-and-frameworks/go-lang.html) / [Flamingo](/languages-and-frameworks/flamingo.html) based backends, +our [Go](/languages-and-frameworks/go-lang/) / [Flamingo](/languages-and-frameworks/flamingo/) based backends, as well as shared libraries we use in all of our projects. The main benefits in that approach are: @@ -19,4 +19,4 @@ The main benefits in that approach are: * Tool consistency over all projects If you take the monorepo approach, of course you want to have a tool to manage it. There are a lot of them on the market -and at AOE we have decided to go with [Nx](/tools/nx.html). +and at AOE we have decided to go with [Nx](/tools/nx/). diff --git a/radar/2022-03-28/pipeline-as-code.md b/radar/2022-03-28/pipeline-as-code.md index e5adb78..a1028a9 100644 --- a/radar/2022-03-28/pipeline-as-code.md +++ b/radar/2022-03-28/pipeline-as-code.md @@ -13,6 +13,6 @@ Continuous Integration and Delivery is an important part in every project. Pipel now be handled like most other parts of your software. The pipeline configuration can run through lint checks, or a test suite before the configuration is shared across teams in your organisation. -Using [container based builds](https://www.aoe.com/techradar/methods-and-patterns/container-based-builds.html) is now +Using [container based builds](/methods-and-patterns/container-based-builds/) is now also the de facto standard. Combining these two techniques enables running isolated builds in an easily reproducible environment so teams can get quick feedback on every change. diff --git a/radar/2022-03-28/resilience-thinking.md b/radar/2022-03-28/resilience-thinking.md index aa5489c..f05333d 100644 --- a/radar/2022-03-28/resilience-thinking.md +++ b/radar/2022-03-28/resilience-thinking.md @@ -19,7 +19,7 @@ patterns and methods used are: * Detect errors explicitly: Check the response message format and configure proper timeouts for external communication * Handle errors in a smart way: Show a nice error message to your customer or, even better, graceful degrade features - e.g. by showing some fallback text -* Use message-based communication where useful ([Decoupling Infrastructure via Messaging](/methods-and-patterns/decoupling-infrastructure-via-messaging.html)) +* Use message-based communication where useful ([Decoupling Infrastructure via Messaging](/methods-and-patterns/decoupling-infrastructure-via-messaging/)) * Use circuit breakers to isolate errors and allow systems to recover * Use short activation paths in your strategic architecture - so that there is only a minimal set of communications between your services required for certain features or business requests diff --git a/radar/2022-03-28/sass.md b/radar/2022-03-28/sass.md index 6caa642..90de8e4 100644 --- a/radar/2022-03-28/sass.md +++ b/radar/2022-03-28/sass.md @@ -7,8 +7,8 @@ featured: false Since the heydays of Sass, the requirements for styling solutions have changed. -With modern solutions like [CSS-in-JS](/methods-and-patterns/css-in-js.html), -[Tailwind](/languages-and-frameworks/tailwindcss.html) or [PostCSS](/tools/postcss.html), you get scoped CSS out of the +With modern solutions like [CSS-in-JS](/methods-and-patterns/css-in-js/), +[Tailwind](/languages-and-frameworks/tailwindcss/) or [PostCSS](/tools/postcss/), you get scoped CSS out of the box and can get rid of the manual and therefore error-prone BEM methodology. Furthermore, mapping class names to elements is no longer necessary. diff --git a/radar/2022-03-28/spring-rest-docs.md b/radar/2022-03-28/spring-rest-docs.md index 702e151..8322fb1 100644 --- a/radar/2022-03-28/spring-rest-docs.md +++ b/radar/2022-03-28/spring-rest-docs.md @@ -5,7 +5,7 @@ quadrant: tools tags: [documentation] --- -[Spring REST Docs](https://spring.io/projects/spring-restdocs/) auto generates [Asciidoctor](http://asciidoctor.org/) snippets with the help of [Spring MVC Test](http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle#spring-mvc-test-framework) or [RestAssured](https://www.aoe.com/techradar/tools/rest-assured.html). +[Spring REST Docs](https://spring.io/projects/spring-restdocs/) auto generates [Asciidoctor](http://asciidoctor.org/) snippets with the help of [Spring MVC Test](http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle#spring-mvc-test-framework) or [RestAssured](/tools/rest-assured/). So you can be sure that your tests are inline with the documentation. -We now use an Api First approach in conjunction with [Open API](https://www.aoe.com/techradar/tools/open-api.html). We see an active community there and a lot of support with this approach. +We now use an Api First approach in conjunction with [Open API](/tools/open-api/). We see an active community there and a lot of support with this approach. diff --git a/radar/2023-02-23/ldap-login.md b/radar/2023-02-23/ldap-login.md index 20ccd28..29c48dc 100644 --- a/radar/2023-02-23/ldap-login.md +++ b/radar/2023-02-23/ldap-login.md @@ -11,5 +11,5 @@ While this worked as some kind of "single credential" model, it does not support WebAuthN, Multi-Factor Authentication, etc. These we do prefer to use integrations using OpenID Connect into SSO solutions such -as [Bare.ID](/platforms-and-aoe-services/bareid.html) or [Keycloak](/tools/keycloak.html), which provide proper +as [Bare.ID](/platforms-and-aoe-services/bareid/) or [Keycloak](/tools/keycloak/), which provide proper authentication and federation for multiple identity sources. diff --git a/radar/2023-02-23/turborepo.md b/radar/2023-02-23/turborepo.md index cfad95a..2666f45 100644 --- a/radar/2023-02-23/turborepo.md +++ b/radar/2023-02-23/turborepo.md @@ -6,7 +6,7 @@ tags: [frontend] --- [Turborepo](https://turbo.build/repo) is a build system for JavaScript and TypeScript project, -which uses a [Monorepo](https://www.aoe.com/techradar/methods-and-patterns/monorepo.html) structure for their codebase. +which uses a [Monorepo](/methods-and-patterns/monorepo/) structure for their codebase. It helps to build projects efficiently by clever caching and resolving dependencies. At the same time, Turborepo is very easy and fast to use and doesn't get in the way. diff --git a/radar/2023-11-01/diagrams-as-code.md b/radar/2023-11-01/diagrams-as-code.md index 8ee20a6..5c00db0 100644 --- a/radar/2023-11-01/diagrams-as-code.md +++ b/radar/2023-11-01/diagrams-as-code.md @@ -7,7 +7,7 @@ tags: [architecture, quality assurance, documentation] Documenting concepts and software architecture as diagrams using code offers significant benefits over heavier solutions. Treating documentation and diagrams as code and checking them into version control increases transparency, collaboration, and productivity. The textual representation of diagrams is easy to write and read, and generating graphical representations as SVG or PNG images is also straightforward with the associated tools. -We extensively use [PlantUML](/tools/plant-uml.html) in combination with [Asciidoc](/tools/asciidoc.html) and tools like [AsciiDoctor Diagram](https://asciidoctor.org/docs/asciidoctor-diagram/) to include and inline PlantUML diagrams in our documentation. The latter allows for a variety of other diagram formats, which can be easily mixed and matched. +We extensively use [PlantUML](/tools/plant-uml/) in combination with [Asciidoc](/tools/asciidoc/) and tools like [AsciiDoctor Diagram](https://asciidoctor.org/docs/asciidoctor-diagram/) to include and inline PlantUML diagrams in our documentation. The latter allows for a variety of other diagram formats, which can be easily mixed and matched. Other tools worth mentioning include: - [Mermaid](https://mermaid.js.org/), a JavaScript-based diagramming tool natively supported by many common tools (e.g., GitHub, GitLab, Gitea, Notion, etc.). diff --git a/radar/2023-11-01/fluentd.md b/radar/2023-11-01/fluentd.md index e69cd6f..f80c50a 100644 --- a/radar/2023-11-01/fluentd.md +++ b/radar/2023-11-01/fluentd.md @@ -5,6 +5,6 @@ quadrant: tools tags: [devops] --- -[Fluentd](https://www.fluentd.org) remains a great tool for collecting logs, transforming them into any required format, and distributing them to various logging backends. However, in recent years, we have often transitioned to [Grafana Loki and Promtail](/platforms-and-aoe-services/loki.html) for several reasons. +[Fluentd](https://www.fluentd.org) remains a great tool for collecting logs, transforming them into any required format, and distributing them to various logging backends. However, in recent years, we have often transitioned to [Grafana Loki and Promtail](/platforms-and-aoe-services/loki/) for several reasons. We've also learned that extensive upfront log parsing carries a risk of losing logs and requires significant effort. This doesn't fit well with most projects. diff --git a/radar/2023-11-01/flux.md b/radar/2023-11-01/flux.md index ee3e2f3..bf34443 100644 --- a/radar/2023-11-01/flux.md +++ b/radar/2023-11-01/flux.md @@ -6,8 +6,8 @@ tags: [frontend] featured: false --- -In the early days of [React](/languages-and-frameworks/react.html), [Flux](https://github.com/facebookarchive/flux) was introduced by Facebook as an architectural pattern for managing global state. Later, it evolved into a library, with contributions from the community. +In the early days of [React](/languages-and-frameworks/react/), [Flux](https://github.com/facebookarchive/flux) was introduced by Facebook as an architectural pattern for managing global state. Later, it evolved into a library, with contributions from the community. -Today, there are numerous libraries that offer the Flux pattern or similar approaches to state management. These include framework-agnostic solutions like [Redux](/languages-and-frameworks/redux.html) or [MobX](https://mobx.js.org/README.html), as well as framework-specific options like [Pinia](https://pinia.vuejs.org/) for Vue and [Zustand](https://docs.pmnd.rs/zustand) for React, among many others. +Today, there are numerous libraries that offer the Flux pattern or similar approaches to state management. These include framework-agnostic solutions like [Redux](/languages-and-frameworks/redux/) or [MobX](https://mobx.js.org/README.html), as well as framework-specific options like [Pinia](https://pinia.vuejs.org/) for Vue and [Zustand](https://docs.pmnd.rs/zustand) for React, among many others. One of the most popular solutions to date is Redux, which is why we use it in several projects. diff --git a/radar/2023-11-01/green-it.md b/radar/2023-11-01/green-it.md index 77fa2dd..df4d3d9 100644 --- a/radar/2023-11-01/green-it.md +++ b/radar/2023-11-01/green-it.md @@ -10,7 +10,7 @@ In an age of ever-increasing digitalization, the energy consumption of data cent ### Sustainable Software Development Practices Well-architected software plays a pivotal role in reducing the environmental impact of digital systems. Sustainability in software development involves the consideration of various factors throughout the entire lifecycle: - **Agile and Modular Development**: Develop software iteratively, focusing on essential functionality and creating modular, reusable components. -- **Programming Language Choice**: Opt for compiled languages such as [Rust](/languages-and-frameworks/rust.html) or [Go](/languages-and-frameworks/go-lang.html) that have lower energy consumption during execution. +- **Programming Language Choice**: Opt for compiled languages such as [Rust](/languages-and-frameworks/rust/) or [Go](/languages-and-frameworks/go-lang/) that have lower energy consumption during execution. - **Automation and Infrastructure-as-Code**: Automate resource management and shut down unused infrastructure during idle periods to decrease energy consumption. - **Demand Shaping**: Schedule energy-intensive workloads to align with the availability of renewable energy sources. - **Green Power**: Source electricity from sustainable and renewable sources. diff --git a/radar/2023-11-01/next-js.md b/radar/2023-11-01/next-js.md index f341b5f..5fa6bdd 100644 --- a/radar/2023-11-01/next-js.md +++ b/radar/2023-11-01/next-js.md @@ -7,6 +7,6 @@ tags: [coding, frontend] We are convinced that Next.js is one of the go-to frameworks for React, and we're excited about the features that version 13 has brought with it. During the Next.js Conf 2022, the team announced some exciting adaptations in this release, but the most interesting one is the new "app" router. In collaboration with the React team, this new routing architecture brings some of the newest and most promising features of React 18 to life. -When using the app router, every component, by default, becomes a [React Server Component](/methods-and-patterns/react-server-components.html), making it one of the first real integrations of this pattern in a framework. The goal is to build complex interfaces while minimizing the amount of JavaScript shipped to the client. Another exciting feature is Streaming, which allows incremental transfer of parts of the UI to the client as they become ready. For example, immediately showing some fallback UI until an asynchronous action is completed, and then streaming the final UI to the client. With the app router, it's also possible to easily create shared layouts that preserve state during navigation and remain interactive. +When using the app router, every component, by default, becomes a [React Server Component](/methods-and-patterns/react-server-components/), making it one of the first real integrations of this pattern in a framework. The goal is to build complex interfaces while minimizing the amount of JavaScript shipped to the client. Another exciting feature is Streaming, which allows incremental transfer of parts of the UI to the client as they become ready. For example, immediately showing some fallback UI until an asynchronous action is completed, and then streaming the final UI to the client. With the app router, it's also possible to easily create shared layouts that preserve state during navigation and remain interactive. The good thing is that this new architecture can coexist alongside the old page router, giving us the flexibility to incrementally adapt to the new features in existing projects. diff --git a/radar/2023-11-01/react-server-components.md b/radar/2023-11-01/react-server-components.md index a511c39..97ebc85 100644 --- a/radar/2023-11-01/react-server-components.md +++ b/radar/2023-11-01/react-server-components.md @@ -11,6 +11,6 @@ This new feature enables the creation of components that exclusively run on the In addition to server components, there are client components, which are essentially the classic components everyone is familiar with. The only distinction is that client components need to be explicitly declared using a directive. Determining which components should be client or server can be one of the more challenging aspects, especially when the goal is to migrate existing applications. -RSCs appear to be most effective when used with Server Side Rendering, although it is possible to use them without it. RSCs and Server Side Rendering complement each other well, as server components are only rendered once on the server and do not need to be sent to the client. Client components are still rendered on the server and then hydrated on the client side. However, with a well-structured application that minimizes client-side code and in combination with React 18's [Suspense and Selective Hydration](https://github.com/reactwg/react-18/discussions/37) features, a performance boost is expected. To test this hypothesis, the React team has collaborated with Vercel, the maintainer of [NextJS](/languages-and-frameworks/next-js.html), to integrate RSCs into a suitable environment early. +RSCs appear to be most effective when used with Server Side Rendering, although it is possible to use them without it. RSCs and Server Side Rendering complement each other well, as server components are only rendered once on the server and do not need to be sent to the client. Client components are still rendered on the server and then hydrated on the client side. However, with a well-structured application that minimizes client-side code and in combination with React 18's [Suspense and Selective Hydration](https://github.com/reactwg/react-18/discussions/37) features, a performance boost is expected. To test this hypothesis, the React team has collaborated with Vercel, the maintainer of [NextJS](/languages-and-frameworks/next-js/), to integrate RSCs into a suitable environment early. Overall, we recognize the potential of this new approach, even though there are several steps to take, particularly for meta-frameworks to achieve production readiness. It appears to be only a matter of time before adoption of React Server Components becomes widespread. This is why we have placed it in the assess ring, keeping a watchful eye on this evolving technology. diff --git a/radar/2023-11-01/react.md b/radar/2023-11-01/react.md index 86cfd69..ee60bdf 100644 --- a/radar/2023-11-01/react.md +++ b/radar/2023-11-01/react.md @@ -5,7 +5,7 @@ quadrant: languages-and-frameworks tags: [coding, frontend] --- -React today is the most widely used frontend library within our company, employed in various forms. Whether it's integrated into frameworks like [NextJS](/languages-and-frameworks/next-js.html) and [Remix](/languages-and-frameworks/remix.html) or utilized for client-side-only applications, React plays a significant role in many of our ongoing projects. Over time, a community of experts has emerged within the company. +React today is the most widely used frontend library within our company, employed in various forms. Whether it's integrated into frameworks like [NextJS](/languages-and-frameworks/next-js/) and [Remix](/languages-and-frameworks/remix/) or utilized for client-side-only applications, React plays a significant role in many of our ongoing projects. Over time, a community of experts has emerged within the company. We firmly believe that React 18, with its range of new features, will further enhance its popularity within our company and the broader community. @@ -13,7 +13,7 @@ We firmly believe that React 18, with its range of new features, will further en While not an entirely new feature, Suspense was initially introduced in a basic version back in 2018. However, it had certain limitations. Its first official use case was code splitting with `React.lazy`, but this feature was only available on the client side, not during server rendering. The primary goal has always been to enhance the loading experience both on the client and server. With React 18, Suspense now enables Streaming server rendering, a new feature that allows React to send the HTML of the loading fallback first and then, after loading completes, send the actual HTML content to the client. The React team continues to work on improving Suspense, particularly to enable data fetching libraries to use it. They are collaborating with authors of some of the most prominent libraries like TanStack Query, SWR, and Apollo. ### Server Components -Server Components represent a new paradigm in React application architecture with the goal of minimizing the amount of JavaScript sent to the client. This approach introduces a new type of component that operates exclusively on the server. It shows great promise, which is why we have given [React Server Components](/methods-and-patterns/react-server-components.html) a dedicated entry on our Tech Radar. +Server Components represent a new paradigm in React application architecture with the goal of minimizing the amount of JavaScript sent to the client. This approach introduces a new type of component that operates exclusively on the server. It shows great promise, which is why we have given [React Server Components](/methods-and-patterns/react-server-components/) a dedicated entry on our Tech Radar. ### Concurrency This is a fundamental update to React's rendering model, primarily occurring under the hood. It introduces the ability to create multiple versions of a user interface concurrently. With concurrent React, rendering can be interrupted, abandoned, and resumed, allowing the application to respond to user interactions immediately, even if it's currently in the middle of rendering. diff --git a/radar/2023-11-01/sketch.md b/radar/2023-11-01/sketch.md index 58a357d..cd65585 100644 --- a/radar/2023-11-01/sketch.md +++ b/radar/2023-11-01/sketch.md @@ -6,4 +6,4 @@ tags: [ux/ui] featured: false --- -Sketch is no longer used by Team XD as we have moved to [Figma](/tools/figma.html) and just finished the last project done in Sketch. +Sketch is no longer used by Team XD as we have moved to [Figma](/tools/figma/) and just finished the last project done in Sketch. diff --git a/radar/2023-11-01/state-management-pattern.md b/radar/2023-11-01/state-management-pattern.md index 249ab8c..c902cf9 100644 --- a/radar/2023-11-01/state-management-pattern.md +++ b/radar/2023-11-01/state-management-pattern.md @@ -5,10 +5,10 @@ quadrant: methods-and-patterns tags: [architecture, coding] --- -State Management is a design pattern with the goal of efficiently sharing state data across components while separating domain representation from state management. This pattern is widely used in many popular web frameworks such as [Vuex](/languages-and-frameworks/vuex.html) or [Redux](/languages-and-frameworks/redux.html). +State Management is a design pattern with the goal of efficiently sharing state data across components while separating domain representation from state management. This pattern is widely used in many popular web frameworks such as [Vuex](/languages-and-frameworks/vuex/) or [Redux](/languages-and-frameworks/redux/). -Especially in [reactive](/methods-and-patterns/reactive-programming.html) systems, this pattern helps in maintaining decoupled, stateless components with immutable data. The implementation of state management varies and depends on the specific requirements of the application at hand. +Especially in [reactive](/methods-and-patterns/reactive-programming/) systems, this pattern helps in maintaining decoupled, stateless components with immutable data. The implementation of state management varies and depends on the specific requirements of the application at hand. -For distributed backend systems, one might consider utilizing [Akka's](/languages-and-frameworks/akka.html) cluster sharding module to elastically manage domain object states. +For distributed backend systems, one might consider utilizing [Akka's](/languages-and-frameworks/akka/) cluster sharding module to elastically manage domain object states. -We employ various state management patterns across most [Vue](/languages-and-frameworks/vue.html) and [React](/languages-and-frameworks/react.html) projects that require them. +We employ various state management patterns across most [Vue](/languages-and-frameworks/vue/) and [React](/languages-and-frameworks/react/) projects that require them.