diff --git a/radar/2021-01-01/dgs.md b/radar/2021-01-01/dgs.md index f55455e..0efad7a 100644 --- a/radar/2021-01-01/dgs.md +++ b/radar/2021-01-01/dgs.md @@ -7,6 +7,6 @@ quadrant: tools The [DGS Framework](https://netflix.github.io/dgs/) is a [GraphQL](https://graphql.org/) server framework based on [Spring Boot](https://spring.io/projects/spring-boot/). It extends [GraphQL Java](https://www.graphql-java.com/) with additional features such as: - an annotation-based programming model for Spring - a test framework for writing query tests as unit tests -- a [Gradle](https://gradle.org/) code gerneration plugin to create types from a GraphQL schema +- a [Gradle](https://gradle.org/) code generation plugin to create types from a GraphQL schema It works well with both Java and Kotlin and allowed us a quick start with getting our first GraphQL servers up and running. diff --git a/radar/2021-01-01/kubernetes-operators.md b/radar/2021-01-01/kubernetes-operators.md index fd6d66b..1b4493b 100644 --- a/radar/2021-01-01/kubernetes-operators.md +++ b/radar/2021-01-01/kubernetes-operators.md @@ -9,4 +9,4 @@ The [Kubernetes Operators](https://kubernetes.io/docs/concepts/extend-kubernetes Kubernetes Operators are widely available for many community projects. These can be shared and found on [operatorhub.io](https://operatorhub.io/). Implementing custom operators is greatly simplified through the [Operators SDK](https://sdk.operatorframework.io/) which is used as base for many [existing implementations](https://github.com/operator-framework/awesome-operators). -We use operators in most projects and prefer them to custom management code. We encourage teams to try the existing community operators for e.g. oberservability and operations tasks. \ No newline at end of file +We use operators in most projects and prefer them to custom management code. We encourage teams to try the existing community operators for e.g. observability and operations tasks. \ No newline at end of file diff --git a/radar/2021-01-01/loki.md b/radar/2021-01-01/loki.md index 1ff63df..bcf7a51 100644 --- a/radar/2021-01-01/loki.md +++ b/radar/2021-01-01/loki.md @@ -7,6 +7,6 @@ featured: true Archiving indexed log-data with a system like Elastic Search can be expensive and archiving it as simple text files makes it hard to query them. [Loki](https://grafana.com/oss/loki/) solves this issue by adding a reference database based on kubernetes-labels to each log-line similar to prometheus, but holding the log-data inside a simple blob-storage like s3. This allows the user to query the data by pre-defined labels and keeps the costs for indexing low. -Another benefit is the fact that does not have an endpoint for mutating log-data wich makes the data immutable from a potential compromised system. +Another benefit is the fact that does not have an endpoint for mutating log-data which makes the data immutable from a potential compromised system. -We at AOE are using it for longer term log-archiving in severaly kubernetes-clusters. \ No newline at end of file +We at AOE are using it for longer term log-archiving in several kubernetes-clusters. \ No newline at end of file diff --git a/radar/2021-01-01/nats.md b/radar/2021-01-01/nats.md index e6abf20..34eaa98 100644 --- a/radar/2021-01-01/nats.md +++ b/radar/2021-01-01/nats.md @@ -7,4 +7,4 @@ featured: true [NATS](https://nats.io/) is a cloud native messaging and stream-data system for modern distributed software systems. Two design-goals [design-goals](https://github.com/nats-io/nats-general/blob/master/architecture/DESIGN.md) were simplicity and performance. These are adopted by selecting [golang](https://golang.org/) for the server implementation and reducing the memory footprint for both: server- and client-side. -The server-side provides simple and efficient horizontal scaling (e.g. deploying it inside kubernetes) and the small client-footprint allows us to use it in embeded-systems, edge-computing and IoT devices e.g. for command and controll use-cases. Also the long list of existing [integrations](https://docs.nats.io/compare-nats#integrations) and the plugin-systems bring a great flexibilty. +The server-side provides simple and efficient horizontal scaling (e.g. deploying it inside kubernetes) and the small client-footprint allows us to use it in embedded-systems, edge-computing and IoT devices e.g. for command and controll use-cases. Also the long list of existing [integrations](https://docs.nats.io/compare-nats#integrations) and the plugin-systems bring a great flexibility. diff --git a/radar/2021-01-01/next-js.md b/radar/2021-01-01/next-js.md index 26b4763..4e7d3d7 100644 --- a/radar/2021-01-01/next-js.md +++ b/radar/2021-01-01/next-js.md @@ -6,4 +6,4 @@ quadrant: languages-and-frameworks [Next.js](https://nextjs.org/) claims itself as **the** React framework for production. It comes with first-class developer experience and many features for example: hybrid static & server-side rendering, TypeScript support, image optimization, code splitting & much more. -We at AOE are already using Next.js for some big projects. The main reason for that is the modern stack (React with TypeScript) and the possibility to render on the server (static prerendering or dynamic SSR) to be able to get crawled by search engines and stay SEO relevant. +We at AOE are already using Next.js for some big projects. The main reason for that is the modern stack (React with TypeScript) and the possibility to render on the server (static pre-rendering or dynamic SSR) to be able to get crawled by search engines and stay SEO relevant. diff --git a/radar/2021-01-01/pulumi.md b/radar/2021-01-01/pulumi.md index 5ad9152..c29e704 100644 --- a/radar/2021-01-01/pulumi.md +++ b/radar/2021-01-01/pulumi.md @@ -5,7 +5,7 @@ quadrant: platforms-and-aoe-services --- [Pulumi](https://www.pulumi.com/) is a tool in the infrastructure-as-code space -that is quite similiar to [Terraform](https://www.terraform.io/) in that it also +that is quite similar to [Terraform](https://www.terraform.io/) in that it also provide a declarative way to provision cloud infrastructure and services. What makes it interesting is that all configuration is done in one of currently 4 supported general-purpose languages/runtimes: @@ -14,7 +14,7 @@ What makes it interesting is that all configuration is done in one of currently * .NET Core * Go -This differs from the Terraform approach which is using it's own domain specific +This differs from the Terraform approach which is using its own domain specific 'Terraform Configuration Language'. While Terraform kept this language intentionally small and limited in functionality in order to make it purely declarative sometimes there is the need to abstract over configuration