docs: streamline formatting and proofreading
This commit is contained in:
committed by
Stefan Rotsch
parent
2c541dfbea
commit
94ac286c34
@@ -5,4 +5,4 @@ quadrant: tools
|
||||
tags: [ux/ui]
|
||||
---
|
||||
|
||||
[Adobe Creative Cloud](https://www.adobe.com/creativecloud.html) transcends traditional design boundaries by providing a comprehensive platform that fosters seamless collaboration and streamlines the design process. We use applications such as Adobe XD, Photoshop, Illustrator, InDesign, and more, each of which serves a unique purpose in the design workflow, including photo and video editing. The integration of these specialized tools allows us to work efficiently and effectively, maximizing our productivity.
|
||||
[Adobe Creative Cloud](https://www.adobe.com/creativecloud.html) transcends traditional design boundaries by providing a comprehensive platform that fosters seamless collaboration and streamlines the design process. We use applications such as Adobe XD, Photoshop, Illustrator, InDesign, and more, each of which serves a unique purpose in the design workflow, including photo and video editing. The integration of these specialized tools allows us to work efficiently and effectively, thus maximizing our productivity.
|
||||
|
||||
@@ -5,10 +5,8 @@ quadrant: languages-and-frameworks
|
||||
tags: [coding, frontend]
|
||||
---
|
||||
|
||||
Angular in version 15 remains a robust and well-maintained front-end framework that continues to build new features on its strong foundation. Angular provides excellent tools for building large-scale applications.
|
||||
[Angular](https://angular.io/), now in version 15, remains a robust and well-maintained front-end framework that continues to build new features on its solid foundation. Angular offers excellent tools for building large-scale applications.
|
||||
|
||||
For example, it comes with the built-in ability to set up and manage a monorepo. This makes sharing components across multiple projects very straightforward. Angular as a framework provides an opinionated approach to solving various problems,
|
||||
reduces decision making in a positive way and provides consistency while still offering enough flexibility where it is needed. Angular 15 stabilizes standalone components, a feature introduced in Angular 14 that aims to further simplify Angular applications.
|
||||
This reduces module complexity, which is a common criticism of Angular.
|
||||
For instance, it includes built-in capabilities for setting up and managing a monorepo, simplifying the sharing of components across multiple projects. As a framework, Angular takes an opinionated approach to solving various problems, reducing the need for extensive decision-making while maintaining consistency, yet still providing flexibility where necessary. Angular 15 further stabilizes standalone components, a feature introduced in Angular 14, with the aim of simplifying Angular applications and reducing module complexity, addressing a common criticism of Angular.
|
||||
|
||||
Upgrading to new versions has become quite easy due to the stable nature of the framework and detailed migration guides provided by the maintainers.
|
||||
The ease of upgrading to new versions has improved significantly due to the framework's stability and the detailed migration guides provided by the maintainers.
|
||||
|
||||
@@ -6,6 +6,4 @@ tags: [devops]
|
||||
featured: false
|
||||
---
|
||||
|
||||
We saw a decrease in our usage of Ansible recently. We focus more on immutable
|
||||
infrastructure using cloud providers. Ansible has still great benefits for mutable infrastructure
|
||||
that needs to be fostered and is a great tool to achieve [Infrastructure as code](../platforms-and-aoe-services/infrastructure-as-code.html) in those cases.
|
||||
We have observed a decrease in our usage of Ansible recently. Our current focus lies more on immutable infrastructure using cloud providers. Nonetheless, Ansible still offers great benefits for mutable infrastructure that require support and is an excellent tool for achieving [Infrastructure as Code](../platforms-and-aoe-services/infrastructure-as-code.html) in such cases.
|
||||
|
||||
@@ -5,4 +5,4 @@ quadrant: platforms-and-aoe-services
|
||||
featured: false
|
||||
---
|
||||
|
||||
We do not use Artifactory anymore and instead rely on the integrated artifact management of SCM platforms like [GitLab](https://gitlab.org/).
|
||||
We no longer use Artifactory; instead, we rely on the integrated artifact management of SCM platforms like [GitLab](https://gitlab.org).
|
||||
|
||||
@@ -2,13 +2,13 @@
|
||||
title: "Azure Container Instances"
|
||||
ring: hold
|
||||
quadrant: platforms-and-aoe-services
|
||||
tags: [devops]
|
||||
tags: [devops]
|
||||
---
|
||||
|
||||
We've previously used AWS Fargate when we didn't require full container orchestration and aimed for simplicity without managing the OS ourselves. When it came to Azure projects, we searched for a similar solution. After exploring the somewhat opaque list of options for running Docker images on Azure, we opted for Azure Container Instances, as they seemed to align most closely with AWS Fargate in terms of simplicity.
|
||||
We've previously used [AWS Fargate](../platforms-and-aoe-services/aws_fargate.html) when we didn't require full container orchestration and aimed for simplicity without managing the OS ourselves. When dealing with Azure projects, we searched for a similar solution. After exploring the somewhat opaque list of options for running Docker images on Azure, we decided on [Azure Container Instances](https://azure.microsoft.com/products/container-instances), as they appeared to align most closely with AWS Fargate in terms of simplicity.
|
||||
|
||||
However, while it's easy to get a container up and running with Azure Container Instances, it appears that this service is still in its early stages of maturity. Some notable limitations include the inability to automatically register containers in internal networks with Azure Application Gateway, lack of support for internal DNS, occasional issues where containers need to be deleted and recreated instead of smoothly replaced, and unexpected container restarts during the night without clear prior announcements or post-incident explanations.
|
||||
However, while it's easy to get a container up and running with Azure Container Instances, it seems that this service is still in its early stages of maturity. Some notable limitations include the inability to automatically register containers in internal networks with Azure Application Gateway, a lack of support for internal DNS, occasional issues where containers need to be deleted and recreated instead of being smoothly replaced, and unexpected container restarts during the night without clear prior announcements or post-incident explanations.
|
||||
|
||||
Another limitation is that volumes can only be stored on Azure File Shares and not on regular Azure Disks. This can pose challenges when running certain applications. Surprisingly, when compared to running the same Docker container on a virtual machine, Azure Container Instances may not even be more cost-effective.
|
||||
Another limitation is that volumes can only be stored on Azure File Shares and not on regular Azure Disks, which can pose challenges when running certain applications. Surprisingly, when compared to running the same Docker container on a virtual machine, Azure Container Instances may not even be more cost-effective.
|
||||
|
||||
Given these limitations and experiences, we would not recommend migrating critical workloads to Azure Container Instances.
|
||||
Given these limitations and experiences, we do not recommend migrating critical workloads to Azure Container Instances.
|
||||
|
||||
@@ -1,22 +1,16 @@
|
||||
---
|
||||
title: "CSS-in-JS"
|
||||
ring: adopt
|
||||
quadrant: methods-and-patterns
|
||||
title: "CSS-in-JS"
|
||||
ring: adopt
|
||||
quadrant: methods-and-patterns
|
||||
tags: [coding, frontend]
|
||||
---
|
||||
|
||||
Since the arrival of react 18, many CSS-in-JS libraries like styled components, emotion and stitches face a big problem.
|
||||
They generate CSS only at runtime and therefore incompatible with streaming and React Server Components.
|
||||
The React developers have written an [article](https://github.com/reactwg/react-18/discussions/110) about this, in which they explicitly advise against CSS-in-JS libraries that generate CSS at runtime.
|
||||
Since the release of React 18, many CSS-in-JS libraries like styled-components, emotion, and stitches have encountered a significant challenge. They generate CSS only at runtime, making them incompatible with streaming and [React Server Components](../methods-and-patterns/react-server-components.html). React developers have addressed this issue in an [article](https://github.com/reactwg/react-18/discussions/110), where they explicitly advise against using CSS-in-JS libraries that generate CSS at runtime.
|
||||
|
||||
This has led to great uncertainty among developers and communities of the affected libraries.
|
||||
Is refactoring possible to turn the runtime libraries into buildtime libraries?
|
||||
So far, none of the libraries have announced anything in this direction and one of the most popular new libraries, stitches, has been [no longer maintained](https://github.com/stitchesjs/stitches/discussions/1149#discussioncomment-6223090).
|
||||
This has created substantial uncertainty among developers and the communities of these affected libraries. The question arises: Is it possible to refactor these runtime libraries into buildtime libraries? To date, none of the libraries have announced any such plans, and, unfortunately, one of the most popular new libraries, stitches, is [no longer being maintained](https://github.com/stitchesjs/stitches/discussions/1149#discussioncomment-6223090).
|
||||
|
||||
Fortunately, more and more CSS-in-JS solutions that generate CSS at buildtime are emerging since then.
|
||||
Libraries like [Vanilla Extract](https://vanilla-extract.style/), [panda](https://panda-css.com/) or [Kuma UI](https://www.kuma-ui.com/) keep the excellent developer experience, compensate the performance disadvantages and are compatible to React 18.
|
||||
Fortunately, there has been a growing number of CSS-in-JS solutions that generate CSS at buildtime. Libraries like [Vanilla Extract](https://vanilla-extract.style/), [panda](https://panda-css.com/), and [Kuma UI](https://www.kuma-ui.com/) maintain an excellent developer experience, overcome performance disadvantages, and are compatible with React 18.
|
||||
|
||||
Unfortunately, these libraries are not yet very widespread and it is difficult to judge how they will develop.
|
||||
Therefore, at AOE we continue to use the established solutions as long as the new React features are not mandatory.
|
||||
Unfortunately, these libraries are not yet widely adopted, and it's challenging to predict how they will develop in the future. Therefore, at AOE, we continue to use established solutions as long as the new React features are not mandatory.
|
||||
|
||||
In addition, we are gaining experience with the new libraries because we see a lot of potential.
|
||||
Moreover, we are gaining experience with these new libraries because we see significant potential in them.
|
||||
|
||||
@@ -10,8 +10,8 @@ tags: [coding]
|
||||
> 'deno'
|
||||
```
|
||||
|
||||
[Deno](https://deno.com/runtime) is a secure, modern JavaScript and TypeScript runtime built on the V8 JavaScript engine. It was developed as a more secure and developer-friendly alternative to Node.js by the core author of node.js, Ryan Dahl.
|
||||
[Deno](https://deno.com/runtime) is a secure, modern JavaScript and TypeScript runtime built on the V8 JavaScript engine. It was developed as a more secure and developer-friendly alternative to Node.js by Ryan Dahl, the core author of Node.js.
|
||||
|
||||
Deno prioritizes security by default, enforcing strict permissions for file system access, network access, and environment variable usage. It also offers improved performance, thanks to its utilization of the latest JavaScript features and optimizations. Deno supports TypeScript out of the box, allowing developers to take advantage of static type checking and other TypeScript features. It incorporates a built-in module system, reducing dependency conflicts and making module management easier.
|
||||
Deno prioritizes security by default, enforcing strict permissions for file system access, network access, and environment variable usage. It also offers improved performance, thanks to its utilization of the latest JavaScript features and optimizations. Deno supports TypeScript out of the box, allowing developers to take advantage of static type checking and other TypeScript features. It incorporates a built-in module system, reducing dependency conflicts and simplifying module management.
|
||||
|
||||
With its streamlined developer experience, including a standard library and support for modern language features, Deno offers a compelling option for JavaScript and TypeScript developers.
|
||||
With its streamlined developer experience, which includes a standard library and support for modern language features, Deno offers a compelling option for JavaScript and TypeScript developers.
|
||||
|
||||
@@ -5,4 +5,4 @@ quadrant: "methods-and-patterns"
|
||||
tags: [ux/ui, frontend, coding, architecture, documentation]
|
||||
---
|
||||
|
||||
By implementing design systems, we have been able to demonstrate that this approach adheres to many of the mentioned benefits and recommend that it be used in future projects.
|
||||
Through the implementation of design systems, we have demonstrated that this approach aligns with many of the mentioned benefits and recommend its use in future projects.
|
||||
|
||||
@@ -5,14 +5,11 @@ quadrant: methods-and-patterns
|
||||
tags: [architecture, quality assurance, documentation]
|
||||
---
|
||||
|
||||
Documenting concepts and software architecture as diagrams using code offers great benefit over heavier solutions.
|
||||
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.
|
||||
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 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.
|
||||
The latter allows a variety of other diagram formats which can be easily mixed and matched.
|
||||
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.
|
||||
|
||||
Other tools worth mentioning are:
|
||||
- [Mermaid](https://mermaid.js.org/) which is a JavaScript based diagramming tool that is natively supported by many common tools (e.g. Github, Gitlab, Gitea, Notion, etc. )
|
||||
- [D2](https://d2lang.com/) is a diagram scripting language with a focus on readability providing a CLI and a Go library to programmatically create diagrams
|
||||
- [Structurizr](https://structurizr.com/) brings his own DSL to create software architecture models based on the [C4 model](https://c4model.com/) and a CLI to export to formats like PlantUML, Mermaid, D2 and others.
|
||||
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.).
|
||||
- [D2](https://d2lang.com/), a diagram scripting language that focuses on readability and provides a CLI and a Go library for programmatically creating diagrams.
|
||||
- [Structurizr](https://structurizr.com/), which brings its own DSL for creating software architecture models based on the [C4 model](https://c4model.com/) and a CLI for exporting to formats like PlantUML, Mermaid, D2, and others.
|
||||
|
||||
@@ -5,25 +5,24 @@ quadrant: methods-and-patterns
|
||||
tags: [devops, documentation, agile]
|
||||
---
|
||||
|
||||
A primary goal of software development organizations is to improve the performance of software delivery and operations.
|
||||
A primary goal of software development organizations is to enhance the performance of software delivery and operations.
|
||||
|
||||
There are a lot of best practices and also different opinions on how to do "devops the right way".
|
||||
We have learned that IT organizations and software delivery are complex issues. This means that most of the time there are no "easy" answers: Instead, contextual continuous improvement is a critical element.
|
||||
There are numerous best practices and differing opinions on how to approach "DevOps the right way." We've learned that IT organizations and software delivery are complex issues, which means that most of the time there are no "easy" answers. Instead, continuous improvement within a contextual framework is a critical element.
|
||||
|
||||
To bring more objectivity and some form of verifiability into this, we like to use the four key metrics suggested by "The state of devops" and "DORA". These four key metrics are
|
||||
To introduce more objectivity and a measure of verifiability, we like to use the four key metrics suggested by "The State of DevOps" and "DORA." These four key metrics are:
|
||||
|
||||
**To evaluate velocity:**
|
||||
- Deployment Frequency (How often a team successfully deploys to production, e.g. daily, weekly, monthly, yearly)
|
||||
- Deployment Frequency (How often a team successfully deploys to production, e.g., daily, weekly, monthly, yearly)
|
||||
- Lead time for changes (the average time it takes to deploy a commit to production)
|
||||
|
||||
**To evaluate stability:**
|
||||
- Time to Restore Services (For a failure, the median time between the deployment that caused the failure and the remediation)
|
||||
- Change Failure Rate (The number of failures per number of deployments)
|
||||
|
||||
## About DORA
|
||||
The DevOps Research and Assessment (DORA) is the largest and longest-running research program of its kind, seeking to understand the capabilities driving software delivery and operations performance. Their report "The State of DevOps" regularly provides insights, observations, and relationships of IT organizations deemed "high performing".
|
||||
### About DORA
|
||||
The DevOps Research and Assessment (DORA) is the largest and longest-running research program of its kind, aiming to understand the capabilities driving software delivery and operations performance. Their report, "The State of DevOps," regularly provides insights, observations, and insights into high-performing IT organizations.
|
||||
|
||||
## Additional Information
|
||||
- https://medium.com/@jezhumble/doras-journey-an-exploration-4c6bfc41e667
|
||||
- https://dora.dev/
|
||||
- https://github.com/dora-team/fourkeys
|
||||
### Additional Information
|
||||
- [DORA Website](https://dora.dev/)
|
||||
- [DORA's Journey: An Exploration](https://medium.com/@jezhumble/doras-journey-an-exploration-4c6bfc41e667)
|
||||
- [DORA GitHub Repository](https://github.com/dora-team/fourkeys)
|
||||
|
||||
@@ -5,7 +5,6 @@ quadrant: tools
|
||||
tags: [devops]
|
||||
---
|
||||
|
||||
[Fluentd](https://www.fluentd.org) is still a great tool to gather logs, transform them into any required format and distribute them to any logging backend.
|
||||
But in recent years we oftentimes transitioned to [Grafana Loki and Promtail](/platforms-and-aoe-services/loki.html) for many 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.html) for several reasons.
|
||||
|
||||
We've also learned that extensive parsing of logs upfront carries some risk of loosing logs and requires a lot of effort. This doesn't fit well with most projects.
|
||||
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.
|
||||
|
||||
@@ -6,12 +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 was also developed as a library along with others from the community.
|
||||
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.
|
||||
|
||||
There are now a number of libraries that offer the Flux pattern or similar approaches to state management.
|
||||
Among them are framework-agnostic solutions like [Redux](/languages-and-frameworks/redux.html) or [MobX](https://mobx.js.org/README.html),
|
||||
but also framework-specific ones like [Pinia](https://pinia.vuejs.org/) (Vue), [Zustand](https://docs.pmnd.rs/zustand) (React) and 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.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.
|
||||
|
||||
One of the most popular solutions so far is Redux, which is why we use it in several projects.
|
||||
One of the most popular solutions to date is Redux, which is why we use it in several projects.
|
||||
|
||||
@@ -5,8 +5,7 @@ quadrant: platforms-and-aoe-services
|
||||
tags: [devops]
|
||||
---
|
||||
|
||||
We continue to use [Harbor](https://goharbor.io) in our projects.
|
||||
Since the last iteration of the AOE Technology Radar, we have discovered existing and new features that we deem useful:
|
||||
We continue to utilize [Harbor](https://goharbor.io) in our projects. Since the last iteration of the AOE Technology Radar, we have discovered both existing and new features that we find useful:
|
||||
|
||||
- an official [Terraform provider](https://registry.terraform.io/providers/goharbor/harbor/latest) for provisioning of Harbor resources via Infrastructure as Code (IaC)
|
||||
- [Proxy Cache](https://goharbor.io/docs/latest/administration/configure-proxy-cache/) projects as pull-through caches for public container registries that can amongst others be used to reduce external network load
|
||||
- An official [Terraform provider](https://registry.terraform.io/providers/goharbor/harbor/latest) for provisioning Harbor resources through Infrastructure as Code (IaC).
|
||||
- The introduction of [Proxy Cache](https://goharbor.io/docs/latest/administration/configure-proxy-cache/) projects, which serve as pull-through caches for public container registries. These can, among other benefits, help reduce external network traffic.
|
||||
|
||||
@@ -2,6 +2,6 @@
|
||||
title: "Infrastructure as Code"
|
||||
ring: adopt
|
||||
quadrant: platforms-and-aoe-services
|
||||
featured: false
|
||||
tags: [devops, ci/cd]
|
||||
tags: [devops, ci/cd]
|
||||
featured: false
|
||||
---
|
||||
|
||||
@@ -2,6 +2,6 @@
|
||||
title: "Jest"
|
||||
ring: adopt
|
||||
quadrant: tools
|
||||
tags: [frontend, quality assurance]
|
||||
tags: [frontend, quality assurance]
|
||||
featured: false
|
||||
---
|
||||
@@ -2,9 +2,8 @@
|
||||
title: "Kubernetes Operators"
|
||||
ring: trial
|
||||
quadrant: methods-and-patterns
|
||||
tags: [devops]
|
||||
tags: [devops]
|
||||
featured: false
|
||||
---
|
||||
|
||||
We faded out Kubernetes Operators as a stand-alone recommendation, because they
|
||||
are such a central part of Kubernetes, that their use seems self-evident.
|
||||
We've faded out Kubernetes Operators as a standalone recommendation because they are such a central part of [Kubernetes](../platforms-and-aoe-services/kubernetes.html) that their use appears self-evident.
|
||||
|
||||
@@ -1,15 +1,13 @@
|
||||
---
|
||||
title: "Loki"
|
||||
ring: adopt
|
||||
quadrant: platforms-and-aoe-services
|
||||
featured: true
|
||||
tags: [ devops ]
|
||||
title: "Loki"
|
||||
ring: adopt
|
||||
quadrant: platforms-and-aoe-services
|
||||
tags: [ devops ]
|
||||
---
|
||||
|
||||
After very good experiences so far, we replaced our ELK stacks with Loki mainly for the following reasons:
|
||||
After having very positive experiences, we decided to replace our ELK stacks with Loki, primarily for the following reasons:
|
||||
|
||||
* Loki is significantly cheaper than the storage requirements of Elasticsearch used in the ELK stack.
|
||||
* The PromQL-like query language that is familiar to users of Prometheus, makes it easier for DevOps and SRE teams who
|
||||
are already using Prometheus for monitoring to work with logs.
|
||||
* Loki's native integration with kubernetes simplifies the setup and configuration process.
|
||||
* Loki typically requires less maintenance and overhead compared to ELK.
|
||||
- Loki is significantly more cost-effective than the storage requirements of Elasticsearch used in the ELK stack.
|
||||
- The PromQL-like query language, familiar to users of Prometheus, makes it easier for DevOps and SRE teams who already use Prometheus for monitoring to work with logs.
|
||||
- Loki's native integration with Kubernetes simplifies the setup and configuration process.
|
||||
- Loki typically requires less maintenance and overhead compared to ELK.
|
||||
|
||||
@@ -14,7 +14,7 @@ While Micro Frontends have gained significant attention as a software architectu
|
||||
|
||||
### Cons:
|
||||
- **Complexity:** Managing multiple codebases, handling cross-cutting concerns such as authentication, routing, and state management, and ensuring a consistent user experience throughout the application can introduce a level of complexity that may not be justified for all projects.
|
||||
- **Performance Overhead:** Increased JavaScript bundle sizes and additional HTTP requests as each module may be loaded separately can impact page load times, especially in low-bandwidth environments. Careful optimization and caching strategies are required to mitigate this issue.
|
||||
- **Performance Overhead:** Increased JavaScript bundle sizes and additional HTTP requests, as each module may be loaded separately, can impact page load times, especially in low-bandwidth environments. Careful optimization and caching strategies are required to mitigate this issue.
|
||||
- **Versioning and Compatibility:** Maintaining compatibility between evolving technologies and frameworks is a substantial challenge. Compatibility issues may arise, requiring additional development and testing efforts.
|
||||
|
||||
Ultimately, the decision of whether to choose Micro Frontends or other architectural approaches should align with the project's goals, team expertise, and scalability requirements. Individual teams working on well-defined, independently deployable features of a large application may benefit from using Micro Frontends. However, for smaller applications or teams with limited resources, a traditional monolithic approach might be more efficient.
|
||||
|
||||
@@ -1,25 +1,22 @@
|
||||
---
|
||||
title: "Monorepo"
|
||||
ring: adopt
|
||||
quadrant: methods-and-patterns
|
||||
featured: true
|
||||
tags: [ coding ]
|
||||
title: "Monorepo"
|
||||
ring: adopt
|
||||
quadrant: methods-and-patterns
|
||||
tags: [coding]
|
||||
---
|
||||
|
||||
### Why We Consider a Monorepo Approach
|
||||
|
||||
Adopting a monorepo approach for our React and Next.js-based projects offers several benefits, _although it may not be
|
||||
the best fit for every project._
|
||||
|
||||
1. More efficient code sharing and reusability
|
||||
2. Consistent Development Environment
|
||||
3. Easier Cross-project Refactoring
|
||||
4. Improved Collaboration
|
||||
5. **Simplified Dependency Management**: In our monorepo, we can manage dependencies at the repository level, which can
|
||||
simplify the process of keeping everything up to date and avoiding version conflicts.
|
||||
1. More efficient code sharing and reusability.
|
||||
2. Consistent development environment.
|
||||
3. Easier cross-project refactoring.
|
||||
4. Improved collaboration.
|
||||
5. **Simplified Dependency Management**: In our monorepo, we can manage dependencies at the repository level, simplifying
|
||||
the process of keeping everything up to date and avoiding version conflicts.
|
||||
6. **Streamlined CI/CD Pipeline**: A single CI/CD pipeline that can build and test all our projects simultaneously.
|
||||
This of course comes with the drawback of a more complicated CI/CD setup and probably longer running pipelines.
|
||||
7. **Better Code Ownership**: It's easier to see who is responsible for each part of the codebase, which can help
|
||||
This, of course, comes with the drawback of a more complicated CI/CD setup and potentially longer running pipelines.
|
||||
7. **Better Code Ownership**: It's easier to determine who is responsible for each part of the codebase, which can
|
||||
improve code ownership and accountability.
|
||||
8. **Simplified Testing**: We can set up end-to-end tests and integration tests that cover the entire application more
|
||||
easily in a monorepo, ensuring that changes in one part of the codebase don't break other parts.
|
||||
@@ -28,5 +25,5 @@ the best fit for every project._
|
||||
|
||||
**However, it is important to note that monorepos are not a one-size-fits-all solution.** They can introduce complexity,
|
||||
especially in very large projects, and may not be suitable for all team sizes or development workflows. The decision to
|
||||
adopt a monorepo should be based on careful consideration of your project's specific requirements, team size, and
|
||||
adopt a monorepo should be based on a careful consideration of your project's specific requirements, team size, and
|
||||
development practices.
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: "NATS"
|
||||
ring: assess
|
||||
quadrant: tools
|
||||
featured: false
|
||||
tags: [architecture, devops]
|
||||
title: "NATS"
|
||||
ring: assess
|
||||
quadrant: tools
|
||||
tags: [architecture, devops]
|
||||
featured: false
|
||||
---
|
||||
|
||||
@@ -1,20 +1,12 @@
|
||||
---
|
||||
title: "Next.js"
|
||||
ring: adopt
|
||||
quadrant: languages-and-frameworks
|
||||
tags: [coding, frontend]
|
||||
title: "Next.js"
|
||||
ring: adopt
|
||||
quadrant: languages-and-frameworks
|
||||
tags: [coding, frontend]
|
||||
---
|
||||
We are still convinced that NextJS is one of the goto frameworks for React and are excited about the features that version
|
||||
13 brought with it. On the NextJS Conf 2022 the team announced some pretty cool adaptions in this release but the most
|
||||
interesting is the new "app" router. In collaboration with the React team, the new routing architecture brings some of the
|
||||
newest and promising features of React 18 to life.
|
||||
|
||||
When using the app router every component by default is a [React Server Component](/methods-and-patterns/react-server-components.html)
|
||||
which is one of the first real integrations of this pattern in a framework. The goal is to build complex interfaces while
|
||||
keeping the amount of JavaScript that's shipped to the client as low as possible. Another exciting feature is Streaming
|
||||
that allows to incrementally transfer parts of the UI to the client when they are 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 is also possible to easily create shared layouts that preserve state on navigation and remain interactive.
|
||||
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.
|
||||
|
||||
The good thing is, that this new architecture can exist besides the old page router. That gives us the possibility to
|
||||
incrementally adapt to the new features in existing projects.
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: "NX"
|
||||
ring: adopt
|
||||
quadrant: tools
|
||||
featured: false
|
||||
tags: [coding, ci/cd]
|
||||
title: "NX"
|
||||
ring: adopt
|
||||
quadrant: tools
|
||||
tags: [coding, ci/cd]
|
||||
featured: false
|
||||
---
|
||||
|
||||
@@ -2,9 +2,8 @@
|
||||
title: "Open Policy Agent"
|
||||
ring: assess
|
||||
quadrant: tools
|
||||
tags: [security, architecture]
|
||||
featured: false
|
||||
tags: [security, architecture]
|
||||
featured: false
|
||||
---
|
||||
|
||||
We have been shifting away from using Open Policy Agent at AOE. For alternatives see
|
||||
[Policy as Code](../methods-and-patterns/policy-as-code.html).
|
||||
We have been transitioning away from using Open Policy Agent at AOE. For alternative solutions, please refer to [Policy as Code](../methods-and-patterns/policy-as-code.html).
|
||||
|
||||
@@ -5,13 +5,13 @@ quadrant: tools
|
||||
tags: [coding, frontend, quality assurance]
|
||||
---
|
||||
|
||||
[Playwright](https://playwright.dev) is a versatile tool for creating reliable end-to-end tests across different browsers, platforms, and languages. It's easy to start with and comes with a wide range of built-in features. It works on Windows, macOS, and Linux, and integrates seamlessly with popular testing frameworks like Jest, Mocha, and Jasmine.
|
||||
[Playwright](https://playwright.dev) is a versatile tool for creating reliable end-to-end tests across different browsers, platforms, and languages. It's easy to get started with and comes with a wide range of built-in features. Playwright works on Windows, macOS, and Linux and seamlessly integrates with popular testing frameworks like Jest, Mocha, and Jasmine.
|
||||
|
||||
Playwright's configuration offers useful options, including native mobile emulation for Chrome on Android and Safari on iOS. It can also be extended using BDD tools like Cucumber or SpecFlow, allowing non-technical contributors to collaborate.
|
||||
Playwright's configuration offers valuable options, including native mobile emulation for Chrome on Android and Safari on iOS. It can also be extended using BDD tools like Cucumber or SpecFlow, allowing non-technical contributors to collaborate.
|
||||
|
||||
Playwright tests are robust, waiting for elements before actions to eliminate timeouts, a common cause of unreliable tests.
|
||||
Playwright tests are robust, as they wait for elements before taking actions to eliminate timeouts, a common cause of unreliable tests.
|
||||
|
||||
In contrast to Cypress, Playwright excels at interacting with different origins and multiple tabs in tests. You can create scenarios with distinct contexts to handle various users within a test, saving authentication states for reuse in other tests. This eliminates repetitive log-in operations.
|
||||
In contrast to Cypress, Playwright excels at interacting with different origins and multiple tabs in tests. You can create scenarios with distinct contexts to handle various users within a test, saving authentication states for reuse in other tests, thus eliminating repetitive log-in operations.
|
||||
|
||||
Developed and maintained by Microsoft, Playwright benefits from extensions for Visual Studio Code, streamlining test development, execution, and debugging.
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
title: "Pulumi"
|
||||
ring: assess
|
||||
quadrant: platforms-and-aoe-services
|
||||
tags: [devops]
|
||||
tags: [devops]
|
||||
featured: false
|
||||
---
|
||||
|
||||
|
||||
@@ -5,6 +5,6 @@ quadrant: languages-and-frameworks
|
||||
tags: [coding, frontend]
|
||||
---
|
||||
|
||||
[React Native](https://reactnative.dev/) is an open-source UI software framework used to build applications for Android, Android TV, iOS, macOS, tvOS, Web, Windows, and UWP by allowing developers to use the React framework along with native platform features.
|
||||
[React Native](https://reactnative.dev/) is an open-source UI software framework used to build applications for Android, Android TV, iOS, macOS, tvOS, Web, Windows, and UWP. It enables developers to utilize the React framework alongside native platform features.
|
||||
|
||||
Developing applications with a single code base can help ensure consistent user experiences across platforms, with the performance advantages of native code.
|
||||
Developing applications with a single codebase can help ensure consistent user experiences across platforms, while also delivering the performance advantages of native code.
|
||||
|
||||
@@ -5,26 +5,12 @@ quadrant: methods-and-patterns
|
||||
tags: [frontend, coding]
|
||||
---
|
||||
|
||||
Shortly after releasing React 17 in October 2020, the team announced React Server Components (RSC) in December 2020 as a working draft.
|
||||
RSCs are described as a new kind of application architecture in React, to reduce the amount of JavaScript that's shipped to the client.
|
||||
The overall goal is to achieve better performance, user experience and maintainability.
|
||||
Shortly after releasing React 17 in October 2020, the team introduced React Server Components (RSC) as a working draft in December 2020. RSCs represent a new application architecture paradigm within React designed to reduce the amount of JavaScript sent to the client. The ultimate goal is to enhance performance, user experience, and maintainability.
|
||||
|
||||
The new feature allows to create components that are running on the server exclusively. That means there will be zero
|
||||
effect on the bundle size that is downloaded by the client. For example libraries that are used in server components are
|
||||
not shipped to the client. RSCs have the ability to access server-side resources (e.g. database, file system) directly.
|
||||
This new feature enables the creation of components that exclusively run on the server. As a result, there is no impact on the bundle size downloaded by the client. For instance, libraries used in server components are not shipped to the client. RSCs also have the capability to access server-side resources, such as databases and the file system, directly.
|
||||
|
||||
Besides server components there are client components that actually are the classic components everyone's known until yet.
|
||||
The only difference is, client components need to be explicitly declared by a directive. To decide which component needs
|
||||
to be client or server might become one of the more challenging parts, especially when migrating existing applications is
|
||||
the goal.
|
||||
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.
|
||||
|
||||
It looks like RSCs are most effectively used with Server Side Rendering, even tho it is possible to use them without it.
|
||||
RSCs and Server Side Rendering complement each other pretty good, because server components are only rendered once on the server and
|
||||
don't need to get shipped to the client. Client components are still rendered on the server and get hydrated afterward.
|
||||
But with a smart application structure where the amount of client side code is reduced to a minimum and in combination
|
||||
with React 18's [Suspense and Selective Hydration](https://github.com/reactwg/react-18/discussions/37) features there is an expected increase in performance. To prove this assumption the React team
|
||||
decided to collaborate with Vercel (maintainer of [NextJS](/languages-and-frameworks/next-js.html)) to integrate early into a fitting environment.
|
||||
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.
|
||||
|
||||
Overall we see the potential of this new approach, even tho there are still several steps to go, especially for the meta
|
||||
frameworks to achieve production readiness. But it seems only a matter of time that adoption of React Server Components
|
||||
will spread. That's why we put it to the assess ring, to keep an eye on this topic.
|
||||
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.
|
||||
|
||||
@@ -2,36 +2,20 @@
|
||||
title: "React.js"
|
||||
ring: adopt
|
||||
quadrant: languages-and-frameworks
|
||||
tags: [coding, frontend]
|
||||
tags: [coding, frontend]
|
||||
---
|
||||
|
||||
React today is the frontend library with the highest distribution inside our company and is used in different varieties.
|
||||
May it be through frameworks like [NextJS](/languages-and-frameworks/next-js.html) and [Remix](/languages-and-frameworks/remix.html)
|
||||
or as client-side-only applications, React can be found in many of our current projects. Over the years there has grown
|
||||
a community with a lot of expertise inside 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.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.
|
||||
|
||||
We are convinced that the following features and many others of React 18 will strengthen its popularity inside the company
|
||||
and the community in general.
|
||||
We firmly believe that React 18, with its range of new features, will further enhance its popularity within our company and the broader community.
|
||||
|
||||
**Suspense**:
|
||||
It isn't a completely new feature as it was already released as a basic version in 2018. But there were some key
|
||||
limitations. Its first official use case was code splitting with `React.lazy`. This was only possible on the client but
|
||||
not during server rendering. The goal always was to improve the loading experience on the client and the server.
|
||||
Now with React 18, Suspense enables a new feature called Streaming server rendering. In short that means React can send
|
||||
the HTML of the loading fallback first and then after loading completes, send the actual HTML content to the client.
|
||||
The React team still has some improvements to do, especially to enable data fetching libraries to use Suspense. Therefor
|
||||
they are collaborating with authors of some of the biggest libraries like TanStack Query, SWR or Apollo.
|
||||
### Suspense
|
||||
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**:
|
||||
It's the name of a new React application architecture paradigm with the goal to reduce the amount of JavaScript sent
|
||||
to the client. The feature introduces a new kind of component that is running on the server exclusively. This new approach
|
||||
is pretty promising, that's why we gave [React Server Components](/methods-and-patterns/react-server-components.html) a dedicated item on our Tech Radar.
|
||||
### 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.
|
||||
|
||||
**Concurrency**:
|
||||
It's a foundational update to React's rendering model. Mostly happening under the hood, it brings the possibility to create
|
||||
multiple versions of a user interface at the same time. With concurrent React, rendering can be interrupted, abandoned and
|
||||
continued which means the application can respond to user interactions immediately if it's currently in a rendering task.
|
||||
### 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.
|
||||
|
||||
|
||||
The React team is working closely with some of the biggest players in the React ecosystem to stabilise and improve the library
|
||||
but also to experiment with new features, which we think is a perfect way to keep React as exciting as it is.
|
||||
The React team is collaborating closely with some of the major players in the React ecosystem to stabilize and enhance the library. They are also experimenting with new features, ensuring that React remains as exciting as ever.
|
||||
|
||||
@@ -7,19 +7,18 @@ tags: [devops, security]
|
||||
|
||||
A Software Bill of Materials (SBOM) is an artifact that consolidates information about the dependencies of a software.
|
||||
|
||||
Multiple standards that define the contents and format of SBOMs exist.
|
||||
The most prominent open-source formats include:
|
||||
Several standards exist that define the contents and format of SBOMs. The most prominent open-source formats include:
|
||||
|
||||
- [CycloneDX](https://cyclonedx.org/) (OWASP): designed in 2017 with the goal to identify vulnerabilities in the software supply chain.
|
||||
- [SPDX](https://spdx.dev/) (Linux Foundation): mainly focused on license compliance in the context of open source software. Support for tracking security vulnerabilities has been added in 2016 with SPDX 2.1.
|
||||
- [CycloneDX](https://cyclonedx.org/) (OWASP): designed in 2017 with the goal of identifying vulnerabilities in the software supply chain.
|
||||
- [SPDX](https://spdx.dev/) (Linux Foundation): primarily focused on license compliance in the context of open source software. Support for tracking security vulnerabilities was added in 2016 with SPDX 2.1.
|
||||
|
||||
While the goals of these SBOM formats vary, they both support
|
||||
While the goals of these SBOM formats vary, they both support:
|
||||
|
||||
- automated generation of SBOMs from source code and
|
||||
- machine-readable output to enable automated processing of SBOMs.
|
||||
- Automated generation of SBOMs from source code.
|
||||
- Machine-readable output to enable automated processing of SBOMs.
|
||||
|
||||
We see potential for SBOMs to improve software supply chain security by facilitating
|
||||
We see the potential for SBOMs to enhance software supply chain security by:
|
||||
|
||||
- transparency regarding direct and transitive software dependencies,
|
||||
- automated detection of software dependencies with known vulnerabilities and
|
||||
- interoperability of security tools that support the same SBOM standards.
|
||||
- Providing transparency regarding direct and transitive software dependencies.
|
||||
- Automating the detection of software dependencies with known vulnerabilities.
|
||||
- Promoting interoperability of security tools that support the same SBOM standards.
|
||||
|
||||
@@ -10,14 +10,12 @@ The serverless pattern, also referred to as Function as a Service (FaaS), repres
|
||||
At AOE, we encourage our development teams to adopt the serverless pattern for its increased scalability, reduced operational overhead, and cost-effectiveness.
|
||||
|
||||
### Common Tools for Developing and Deploying Serverless Applications
|
||||
|
||||
- **[AWS SAM (Serverless Application Model)](https://aws.amazon.com/serverless/sam/):** An AWS-native tool that simplifies the deployment of serverless applications on Amazon Web Services (AWS). It supports multiple programming languages.
|
||||
- **[Azure Functions Core Tools](https://github.com/Azure/azure-functions-core-tools/):** Seamless development, debugging, and deployment of serverless functions on Microsoft Azure. Integrates with Visual Studio Code.
|
||||
- **[Google Cloud Functions Framework](https://cloud.google.com/functions/docs/functions-framework/):** A local development environment, debugging capabilities, and a framework that integrates with other Google Cloud services. Supports multiple programming languages, including Node.js, Python, Go, and others.
|
||||
- **[OpenFaaS](https://www.openfaas.com/):** Build and deploy serverless functions using Docker containers on Kubernetes. Provides flexibility in containerization and language choice.
|
||||
- **[AWS SAM (Serverless Application Model)](https://aws.amazon.com/serverless/sam/):** An AWS-native tool that simplifies the deployment of serverless applications on Amazon Web Services (AWS) and supports multiple programming languages.
|
||||
- **[Azure Functions Core Tools](https://github.com/Azure/azure-functions-core-tools/):** Provide seamless development, debugging, and deployment of serverless functions on Microsoft Azure. These tools integrate with Visual Studio Code.
|
||||
- **[Google Cloud Functions Framework](https://cloud.google.com/functions/docs/functions-framework/):** Offer a local development environment, debugging capabilities, and a framework that integrates with other Google Cloud services. It supports multiple programming languages, including Node.js, Python, Go, and others.
|
||||
- **[OpenFaaS](https://www.openfaas.com/):** Allow building and deploying serverless functions using Docker containers on Kubernetes. They provide flexibility in containerization and language choice.
|
||||
|
||||
### Popular FaaS Providers
|
||||
|
||||
- **[AWS Lambda](https://aws.amazon.com/lambda/):** Amazon Web Services' serverless compute service with extensive language support and deep integration with AWS services.
|
||||
- **[Azure Functions](https://azure.microsoft.com/services/functions/):** Microsoft Azure's serverless platform supporting multiple programming languages and seamless Azure service integration.
|
||||
- **[Google Cloud Functions](https://cloud.google.com/functions):** Google Cloud's serverless platform optimized for event-driven applications and simplified serverless development.
|
||||
@@ -26,8 +24,7 @@ At AOE, we encourage our development teams to adopt the serverless pattern for i
|
||||
|
||||
### When to Apply the Serverless Pattern
|
||||
|
||||
Embracing the Serverless pattern can significantly enhance development speed, scalability, and cost-effectiveness in modern software architectures, e.g., with:
|
||||
|
||||
Embracing the Serverless pattern can significantly enhance development speed, scalability, and cost-effectiveness in modern software architectures. For example:
|
||||
- **Event-Driven Workloads:** Serverless is ideal for applications with sporadic or unpredictable workloads driven by events like user actions, sensor data, or file uploads.
|
||||
- **Scaling Microservices:** Adopt serverless for specific microservices within a larger architecture to simplify deployment and scale.
|
||||
- **Cost Optimization:** Use serverless to optimize costs by paying only for the resources consumed during execution.
|
||||
|
||||
@@ -2,9 +2,7 @@
|
||||
title: "Service Mesh"
|
||||
ring: trial
|
||||
quadrant: platforms-and-aoe-services
|
||||
tags: [architecture, devops, security]
|
||||
|
||||
tags: [architecture, devops, security]
|
||||
---
|
||||
|
||||
We are using Service Meshes now in multiple projects.
|
||||
Especially mTLS is a great feature that we feel almost all projects will benefit from.
|
||||
We have implemented Service Meshes in multiple projects. In particular, mTLS is a valuable feature that we believe almost all projects can benefit from.
|
||||
|
||||
@@ -5,17 +5,8 @@ quadrant: platforms-and-aoe-services
|
||||
tags: [devops, security]
|
||||
---
|
||||
|
||||
[Sigstore](https://www.sigstore.dev) is a project by The Linux Foundation® aimed at developing a standard
|
||||
for signing and verifying container images.
|
||||
[Sigstore](https://www.sigstore.dev) is a project by The Linux Foundation® aimed at developing a standard for signing and verifying container images.
|
||||
|
||||
Although its primary benefit is signing and verifying public images, it can also be used for internal images.
|
||||
Its central tool, `cosign`, allows the signing of container artifacts using a private key within a CI pipeline.
|
||||
This enables us to track which job built a specific image and identify the associated code base. Furthermore,
|
||||
it prevents any malicious entity from tampering with an image or building an image from an unknown source
|
||||
outside the CI pipeline.
|
||||
While its primary benefit is signing and verifying public images, it can also be used for internal images. Its central tool, `cosign`, allows the signing of container artifacts using a private key within a CI pipeline. This approach enables us to track which job built a specific image and identify the associated codebase. Furthermore, it prevents any malicious entity from tampering with an image or building an image from an unknown source outside the CI pipeline.
|
||||
|
||||
With support and funding from The Linux Foundation, as well as its relatively low integration effort, we believe
|
||||
this project has the potential to become the standard for signing container images in Open Source projects.
|
||||
[Kubernetes has already begun signing their release artifacts](https://github.com/kubernetes/enhancements/issues/3031)
|
||||
with cosign, and we anticipate that other entities will also adopt it. Therefore, in the future, this ecosystem
|
||||
could serve as a reliable means of verifying the authenticity of public images.
|
||||
With support and funding from The Linux Foundation and its relatively low integration effort, we believe this project has the potential to become the standard for signing container images in open-source projects. [Kubernetes has already begun signing their release artifacts](https://github.com/kubernetes/enhancements/issues/3031) with cosign, and we anticipate that other entities will also adopt it. Therefore, in the future, this ecosystem could serve as a reliable means of verifying the authenticity of public images.
|
||||
|
||||
@@ -6,4 +6,4 @@ tags: [ci/cd, quality assurance]
|
||||
featured: false
|
||||
---
|
||||
|
||||
SonarQube is still a good choice for checking your code quality. When using GitLab pipelines, it can be replaced with the built-in functionality of [GitLab](https://docs.gitlab.com/ee/ci/testing/code_quality.html).
|
||||
SonarQube remains a good choice for checking your code quality. However, when using GitLab pipelines, it can be replaced with the built-in functionality provided by [GitLab](https://docs.gitlab.com/ee/ci/testing/code_quality.html).
|
||||
|
||||
@@ -6,5 +6,4 @@ tags: [coding, quality assurance]
|
||||
featured: false
|
||||
---
|
||||
|
||||
Most projects at AOE moved away from Groovy and other testing frameworks for JVM languages are way more advanced
|
||||
or comfortable in their usage. Because of that, mentioning Spock seems no longer relevant.
|
||||
Most projects at AOE have transitioned away from Groovy, and other testing frameworks for JVM languages are more advanced and user-friendly. Consequently, mentioning Spock no longer seems relevant.
|
||||
|
||||
@@ -5,12 +5,10 @@ quadrant: methods-and-patterns
|
||||
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) 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.html) or [Redux](/languages-and-frameworks/redux.html).
|
||||
|
||||
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.
|
||||
The ways of implementing state management differs and depends on the specific requirements of the application at hand.
|
||||
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.
|
||||
|
||||
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 consider utilizing [Akka's](/languages-and-frameworks/akka.html) 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 employ various state management patterns across most [Vue](/languages-and-frameworks/vue.html) and [React](/languages-and-frameworks/react.html) projects that require them.
|
||||
|
||||
@@ -5,4 +5,4 @@ quadrant: languages-and-frameworks
|
||||
tags: [coding, frontend]
|
||||
---
|
||||
|
||||
Stitches is [no longer being actively maintained](https://github.com/stitchesjs/stitches/discussions/1149#discussioncomment-6223090) due to compatibility issues with CSS-in-JS runtime injection and React 18 Server Components. Thus, we do not recommend using it for new projects.
|
||||
Stitches is [no longer actively maintained](https://github.com/stitchesjs/stitches/discussions/1149#discussioncomment-6223090) due to compatibility issues with CSS-in-JS runtime injection and React 18 Server Components. Therefore, we do not recommend using it for new projects.
|
||||
|
||||
@@ -5,8 +5,8 @@ quadrant: "languages-and-frameworks"
|
||||
tags: [coding, frontend]
|
||||
---
|
||||
|
||||
We have some smaller Svelte projects at AOE. There are some features we would like to use and explore further, like
|
||||
We have some smaller [Svelte](https://svelte.dev/) projects at AOE, and there are some features we would like to further explore, such as:
|
||||
|
||||
- can be used together with other libraries or frameworks
|
||||
- server-side rendering by default
|
||||
- super fast
|
||||
- Compatibility with other libraries or frameworks
|
||||
- Server-side rendering by default
|
||||
- Exceptional performance
|
||||
|
||||
@@ -1,11 +1,12 @@
|
||||
---
|
||||
title: "TypeScript"
|
||||
ring: adopt
|
||||
quadrant: languages-and-frameworks
|
||||
tags: [coding, frontend]
|
||||
title: "TypeScript"
|
||||
ring: adopt
|
||||
quadrant: languages-and-frameworks
|
||||
tags: [coding, frontend]
|
||||
---
|
||||
|
||||
Typescript has become more widely used and has become the industry standard for most JavaScript projects.
|
||||
Typescript brings all the means to avoid errors in development, refactor code, scale projects, and improve
|
||||
code collaboration. Its widespread use and large community help to further improve and document the language.
|
||||
Typescript is our language of choice for existing and future projects to write robust and clean JavaScript code.
|
||||
TypeScript has become more widely used and is now considered the industry standard for most JavaScript projects and provides the means to prevent errors during development, refactor code, scale projects, and enhance code collaboration.
|
||||
|
||||
Its widespread adoption and the support of a large community contribute to further improving and documenting the language.
|
||||
|
||||
TypeScript is our language of choice for both existing and future projects, allowing us to write robust and clean JavaScript code.
|
||||
|
||||
@@ -5,8 +5,10 @@ quadrant: tools
|
||||
tags: [frontend, coding]
|
||||
---
|
||||
|
||||
As modern browsers nowadays allow native usage of [ES Modules](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules) it is possible to use it for improving frontend development which is the goal of [Vite](https://vitejs.dev/guide/why.html).
|
||||
Since it's announcement in 2020, Vite picked up a lot of attention and was able to grow a large community providing pluggable features.
|
||||
Vite brings two things, a native ESM based dev-server and a bundler for production builds.
|
||||
The dev-server features an improved performance during development as modules are loaded and transpiled only on demand. This leads to faster cold-start times and quicker HMR.
|
||||
We see Vite as a stable and production ready tool, and would recommend it for upcoming projects.
|
||||
As modern browsers now support the native usage of [ES Modules](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules), it's possible to use them to enhance frontend development, which is the goal of [Vite](https://vitejs.dev/guide/why.html).
|
||||
|
||||
Since its announcement in 2020, Vite has garnered significant attention and has grown a large community that provides pluggable features. Vite offers two key components: a native ESM-based development server and a bundler for production builds.
|
||||
|
||||
The development server boasts improved performance during development, as modules are loaded and transpiled only on demand. This leads to faster cold-start times and quicker Hot Module Replacement (HMR) support.
|
||||
|
||||
We consider Vite to be a stable and production-ready tool, and we would recommend it for upcoming projects.
|
||||
|
||||
@@ -2,11 +2,11 @@
|
||||
title: "Vue.js"
|
||||
ring: adopt
|
||||
quadrant: languages-and-frameworks
|
||||
tags: [coding, frontend]
|
||||
tags: [coding, frontend]
|
||||
---
|
||||
|
||||
[Vue](https://vuejs.org/guide/introduction.html) is a progressive, incrementally adoptable framework for building user interfaces, known for its simplicity and flexibility. The core library is view-focused, making it easy to integrate with other libraries and existing projects. It excels in powering single-page applications when combined with supporting libraries like [Pinia](https://pinia.vuejs.org), [vue-router](https://router.vuejs.org) and [VueUse](https://vueuse.org), but can also be used for building server-side rendered and statically generated web applications with the [Nuxt framework](https://nuxt.com).
|
||||
[Vue](https://vuejs.org/guide/introduction.html) is a progressive and incrementally adoptable framework for building user interfaces, renowned for its simplicity and flexibility. The core library focuses on views, making it easy to integrate with other libraries and existing projects. It excels in powering single-page applications when combined with supporting libraries like [Pinia](https://pinia.vuejs.org), [vue-router](https://router.vuejs.org), and [VueUse](https://vueuse.org). However, it's also versatile enough to build server-side rendered and statically generated web applications using the [Nuxt framework](https://nuxt.com).
|
||||
|
||||
The HTML-based template syntax in Vue allows for declarative binding of the rendered DOM to the underlying Vue instance's data, which, in combination with the [reactivity system](https://vuejs.org/guide/extras/reactivity-in-depth.html), ensures high performance by intelligently determining the minimal amount of components to re-render and applying the minimal amount of DOM manipulations when the app-state changes. Additionally, applications can be organized into [Single File Components](https://vuejs.org/guide/scaling-up/sfc.html), each containing the template (HTML), style (CSS), and functionality (JS). The [Composition API and 'script setup'](https://vuejs.org/api/sfc-script-setup.html)-syntax further enhance code readability and modularity, promoting reusability and maintainability throughout the development process.
|
||||
Vue's HTML-based template syntax enables declarative binding of the rendered DOM to the underlying Vue instance's data. This, in conjunction with the [reactivity system](https://vuejs.org/guide/extras/reactivity-in-depth.html), ensures high performance by intelligently determining the minimal components to re-render and applying the minimal DOM manipulations when the app-state changes. Furthermore, applications can be organized into [Single File Components](https://vuejs.org/guide/scaling-up/sfc.html), each containing the template (HTML), style (CSS), and functionality (JS). The [Composition API and 'script setup'](https://vuejs.org/api/sfc-script-setup.html) syntax further enhance code readability and modularity, promoting reusability and maintainability throughout the development process.
|
||||
|
||||
Vue brings powerful features, such as Teleport, allowing components to render at any position on the page, and Fragment, which removes the requirement for a single root element in a template. Additionally, Vue delivers enhanced performance through Tree-Shaking, reducing bundle size and Compiler-informed Virtual DOM optimizations, leading to faster initial renders and updates while consuming less memory.
|
||||
Vue introduces powerful features like Teleport, which enables components to render at any position on the page, and Fragment, removing the requirement for a single root element in a template. Additionally, Vue enhances performance through Tree-Shaking, reducing bundle size, and Compiler-informed Virtual DOM optimizations, resulting in faster initial renders and updates while consuming less memory.
|
||||
|
||||
@@ -6,4 +6,4 @@ tags: [frontend, coding]
|
||||
featured: false
|
||||
---
|
||||
|
||||
Webpack still is one of, if not even the most used bundler by now. The team behind is continuously fixing bugs and adding new features that are released in major version updates. Even if there were new bundlers coming up in recent years, we still can recommend using Webpack.
|
||||
Webpack remains one of the, if not the most, widely used bundlers. The team behind it is continually fixing bugs and adding new features, which are released in major version updates. Despite the emergence of new bundlers in recent years, we still recommend using Webpack.
|
||||
|
||||
@@ -6,8 +6,8 @@ tags: [frontend, coding]
|
||||
featured: false
|
||||
---
|
||||
|
||||
We decided to move Yarn to the adopt ring as it has continued to establish itself in the last years and has successfully
|
||||
been used in many of our projects. It continues to offer better performance than npm and in addition offers both
|
||||
offline installation and the Plug'n'Play approach. With Plug'n'Play mode Yarn replaces the node_modules directory
|
||||
with a virtual filesystem in order to improve performance and save disk space. Yarn is a good choice for monorepos
|
||||
due to the support of workspaces and is absolutely recommended as a package manager.
|
||||
We have decided to move Yarn into the "adopt" ring as it has continued to establish itself in recent years and has proven to be successful in many of our projects.
|
||||
|
||||
Yarn consistently offers better performance than npm and, in addition, provides both offline installation and the Plug'n'Play approach. With Plug'n'Play mode, Yarn replaces the node_modules directory with a virtual file system to enhance performance and save disk space.
|
||||
|
||||
Yarn is an excellent choice for monorepos, thanks to its support for workspaces, and is highly recommended as a package manager.
|
||||
|
||||
Reference in New Issue
Block a user