docs: fix blog description (#1836)

apache · Dec 9, 2024 · cf3fb4e · cf3fb4e
1 parent add3e55
commit cf3fb4e
Show file tree

Hide file tree

Showing 7 changed files with 30 additions and 70 deletions.
diff --git a/blog/en/blog/2023/03/16/grpc-client-side.md b/blog/en/blog/2023/03/16/grpc-client-side.md
@@ -18,21 +18,21 @@ tags: [Ecosystem]
 image: https://static.apiseven.com/uploads/2023/06/08/DOxFlzQc_grpc.svg
 ---
 
->Most inter-systems communication components that use REST serialize their payload in JSON. As of now, JSON lacks a widely-used schema validation standard: [JSON Schema](https://json-schema.org/) is not widespread. Standard schema validation allows delegating the validation to a third-party library and being done with it. Without one, we must fall back to manual validation in the code. Worse, we must keep the validation code in sync with the schema.
->
->XML has schema validation out-of-the-box: an XML document can declare a grammar that it must conform to. SOAP, being based on XML, benefits from it too.
->
->Other serialization alternatives have a schema validation option: _e.g._, [Avro](https://avro.apache.org/), [Kryo](https://github.com/EsotericSoftware/kryo) and [Protocol Buffers](https://protobuf.dev/). Interestingly enough, gRPC uses Protobuf to offer RPC across distributed components:
+>In this post, we will briefly describe gRPC and how it benefits inter-service communication.
 
 <!--truncate-->
 
 <head>
     <link rel="canonical" href="https://blog.frankel.ch/grpc-client-side/" />
 </head>
 
->gRPC is a modern open source high performance Remote Procedure Call (RPC) framework that can run in any environment. It can efficiently connect services in and across data centers with pluggable support for load balancing, tracing, health checking and authentication. It is also applicable in last mile of distributed computing to connect devices, mobile applications and browsers to backend services.
->
->-- [Why gRPC?](https://grpc.io/)
+Most inter-systems communication components that use REST serialize their payload in JSON. As of now, JSON lacks a widely-used schema validation standard: [JSON Schema](https://json-schema.org/) is not widespread. Standard schema validation allows delegating the validation to a third-party library and being done with it. Without one, we must fall back to manual validation in the code. Worse, we must keep the validation code in sync with the schema.
+
+XML has schema validation out-of-the-box: an XML document can declare a grammar that it must conform to. SOAP, being based on XML, benefits from it too.
+
+Other serialization alternatives have a schema validation option: _e.g._, [Avro](https://avro.apache.org/), [Kryo](https://github.com/EsotericSoftware/kryo) and [Protocol Buffers](https://protobuf.dev/). Interestingly enough, gRPC uses Protobuf to offer RPC across distributed components:
+
+gRPC is a modern open source high performance Remote Procedure Call (RPC) framework that can run in any environment. It can efficiently connect services in and across data centers with pluggable support for load balancing, tracing, health checking and authentication. It is also applicable in last mile of distributed computing to connect devices, mobile applications and browsers to backend services. -- [Why gRPC?](https://grpc.io/)
 
 Moreover, Protocol is a _binary_ serialization mechanism, saving a lot of bandwidth. Thus, gRPC is an excellent option for inter-systems communication. But if all your components talk gRPC, how can simple clients call them? In this post, we will build a gRPC service and show how to call it from curl.
 

diff --git a/blog/en/blog/2023/08/17/ops-friendly-apisix.md b/blog/en/blog/2023/08/17/ops-friendly-apisix.md
@@ -18,18 +18,18 @@ tags: [Ecosystem]
 image: https://static.apiseven.com/2022/10/19/634f6677742a1.png
 ---
 
->Though I always worked on the Dev side of IT, I was also interested in the Ops side. I even had a short experience being a WebSphere admin: I used it several times, helping Ops deal with the Admin console while being a developer.
->
->Providing a single package that Ops can configure and deploy in different environments is very important. As a JVM developer, I've been happy using Spring Boot and its wealth of configuration options: command-line parameters, JVM parameters, files, profiles, environment variables, etc.
->
->In this short post, I'd like to describe how you can do the same with Apache APISIX in the context of containers.
+>In this short post, I'd like to describe how to leverage Apache APISIX in containers, drawing on personal experiences with Spring Boot and WebSphere administration.
 
 <!--truncate-->
 
 <head>
     <link rel="canonical" href="https://blog.frankel.ch/ops-friendly-apisix/" />
 </head>
 
+Though I always worked on the Dev side of IT, I was also interested in the Ops side. I even had a short experience being a WebSphere admin: I used it several times, helping Ops deal with the Admin console while being a developer.
+
+Providing a single package that Ops can configure and deploy in different environments is very important. As a JVM developer, I've been happy using Spring Boot and its wealth of configuration options: command-line parameters, JVM parameters, files, profiles, environment variables, etc.
+
 ## File-based configuration
 
 The foundation of configuring Apache APISIX is file-based. The default values are found in the `/usr/local/apisix/conf/apisix/config-default.yaml` configuration file. For example, by default, Apache APISIX runs on port `9080`, and the admin port is `9180`. That's because of the default configuration:

diff --git a/blog/en/blog/2023/10/05/resize-images-on-the-fly.md b/blog/en/blog/2023/10/05/resize-images-on-the-fly.md
@@ -19,25 +19,27 @@ tags: [Ecosystem]
 image: https://static.apiseven.com/uploads/2023/10/03/LuagzWfs_camera-514992.jpg
 ---
 
->As a web architect, one of the many issues is asset management. And the most significant issue in assets is images. A naive approach would be to set an image and let the browser resize the image via CSS:
->
+>This blog xplores effective strategies for image asset management in web architecture, highlighting traditional and innovative solutions to optimize delivery and avoid reliance on CSS resizing.
+
+<!--truncate-->
+
+<head>
+    <link rel="canonical" href="https://blog.frankel.ch/resize-images-on-the-fly/" />
+</head>
+
+As a web architect, one of the many issues is asset management. And the most significant issue in assets is images. A naive approach would be to set an image and let the browser resize the image via CSS:
+
 >```css
 >img {
 >    height: 100%;
 >    width: 100%;
 >    object-fit: contain;
 >}
 >```
->
->However, it means that you download the original image. It entails two problems: the size of the original image and the suboptimal browser-based resizing.
->
->This post will cover two alternatives: traditional and brand-new solutions.
 
-<!--truncate-->
+However, it means that you download the original image. It entails two problems: the size of the original image and the suboptimal browser-based resizing.
 
-<head>
-    <link rel="canonical" href="https://blog.frankel.ch/resize-images-on-the-fly/" />
-</head>
+This post will cover two alternatives: traditional and brand-new solutions.
 
 ## Ahead-of-time resizing
 

diff --git a/blog/en/blog/2023/11/09/api-versioning.md b/blog/en/blog/2023/11/09/api-versioning.md
@@ -20,17 +20,17 @@ image: https://static.apiseven.com/uploads/2023/11/06/PjxXv0E9_signpost-3691159.
 ---
 
 >In my previous post [Evolving your APIs](https://blog.frankel.ch/evolve-apis/), I mention the main API versioning approaches. During the talk of the same name, I sometimes get some questions on the subject. In this post, I'll detail each of them.
->
->I assume readers know the reasons behind versioning, semantic versioning, and product lifecycle. If not, I encourage you to read a bit about these themes; in particular, chapter 24 of the excellent [API Design Patterns](https://blog.frankel.ch/api-design-patterns/) book focuses on them.
->
->I'll summarize the subject in a few words in any case.
 
 <!--truncate-->
 
 <head>
     <link rel="canonical" href="https://blog.frankel.ch/api-versioning/" />
 </head>
 
+I assume readers know the reasons behind versioning, semantic versioning, and product lifecycle. If not, I encourage you to read a bit about these themes; in particular, chapter 24 of the excellent [API Design Patterns](https://blog.frankel.ch/api-design-patterns/) book focuses on them.
+
+I'll summarize the subject in a few words in any case.
+
 ## Generalities
 
 Software naturally evolves, because of business need or changing regulations. In some cases, the said software has no clients but humans, _e.g._, a monolith with Server-Side Rendering. In all other cases, at least another software component interacts with your software:

diff --git a/blog/en/blog/2024/02/13/apisix-owasp-coraza-core-ruleset.md b/blog/en/blog/2024/02/13/apisix-owasp-coraza-core-ruleset.md
@@ -21,12 +21,6 @@ image: https://static.apiseven.com/uploads/2024/02/10/vVlFQu7C_img-HDlf4Xx9m1iqS
     <link rel="canonical" href="https://blog.frankel.ch/apisix-owasp-coraza-core-ruleset/" />
 </head>
 
->The Open Worldwide Application Security Project is an online community that produces freely available articles, methodologies, documentation, tools, and technologies in the fields of IoT, system software and web application security. The OWASP provides free and open resources. It is led by a non-profit called The OWASP Foundation. The OWASP Top 10 - 2021 is the published result of recent research based on comprehensive data compiled from over 40 partner organizations.
->
-> --[OWASP website](https://owasp.org/)
->
->The OWASP regularly publishes a Top 10 vulnerability report. The report targets vulnerabilities in web applications.
->
 >In this post, I'd like to describe how to fix some of them via the [Apache APISIX API Gateway](https://apisix.apache.org/).
 
 <!--truncate-->

diff --git a/blog/en/blog/2024/02/20/secure-api-practices-apisix-1.md b/blog/en/blog/2024/02/20/secure-api-practices-apisix-1.md
@@ -25,23 +25,6 @@ image: https://static.apiseven.com/uploads/2024/02/15/kgIjhRXf_img-BuLDzx81CexYQ
 
 >A couple of months ago, I stumbled upon this list of  Secure your API with these [16 practices to secure your API](https://www.linkedin.com/posts/brijpandeyji_secure-your-api-with-these-16-practices-activity-7094020647529369601-5kzQ/):
 >
-> 1. Authentication 🕵️️ - Verifies the identity of users accessing APIs.
-> 2. Authorization 🚦 - Determines permissions of authenticated users.
-> 3. Data Redaction 🖍️ - Obscures sensitive data for protection.
-> 4. Encryption 🔒 - Encodes data so only authorized parties can decode it.
-> 5. Error Handling ❌ - Manages responses when things go wrong, avoiding revealing sensitive info.
-> 6. Input Validation & Data Sanitization 🧹 - Checks input data and removes harmful parts.
-> 7. Intrusion Detection Systems 👀 - Monitor networks for suspicious activities.
-> 8. IP Whitelisting 📝 - Permits API access only from trusted IP addresses.
-> 9. Logging and Monitoring 🖥️ - Keeps detailed logs and regularly monitors APIs.
->10. Rate Limiting ⏱️ - Limits user requests to prevent overload.
->11. Secure Dependencies 📦 - Ensures third-party code is free from vulnerabilities.
->12. Security Headers 📋 - Enhances site security against types of attacks like XSS.
->13. Token Expiry ⏳ - Regularly expiring and renewing tokens prevents unauthorized access.
->14. Use of Security Standards and Frameworks 📘 - Guides your API security strategy.
->15. Web Application Firewall 🔥 - Protects your site from HTTP-specific attacks.
->16. API Versioning 🔄 - Maintains different versions of your API for seamless updates.
->
 >While it's debatable whether some points relate to security, _e.g.,_, versioning, the list is a good starting point anyway. In this two-post series, I'd like to describe how we can implement each point with Apache APISXI (or not).
 
 <!--truncate-->

diff --git a/blog/en/blog/2024/02/27/secure-api-practices-apisix-2.md b/blog/en/blog/2024/02/27/secure-api-practices-apisix-2.md
@@ -23,26 +23,7 @@ image: https://static.apiseven.com/uploads/2024/02/15/kgIjhRXf_img-BuLDzx81CexYQ
     <link rel="canonical" href="https://blog.frankel.ch/secure-api-practices-apisix/2/" />
 </head>
 
->[Last week](https://blog.frankel.ch/secure-api-practices-apisix/1/), we listed 16 practices to help secure one's APIs and described how to implement them with Apache APISIX.
->
-> 1. ~~Authentication 🕵️️ - Verifies the identity of users accessing APIs.~~
-> 2. ~~Authorization 🚦 - Determines permissions of authenticated users.~~
-> 3. Data Redaction 🖍️ - Obscures sensitive data for protection.
-> 4. Encryption 🔒 - Encodes data so only authorized parties can decode it.
-> 5. Error Handling ❌ - Manages responses when things go wrong, avoiding revealing sensitive info.
-> 6. ~~Input Validation & Data Sanitization 🧹 - Checks input data and removes harmful parts.~~
-> 7. Intrusion Detection Systems 👀 - Monitor networks for suspicious activities.
-> 8. ~~IP Whitelisting 📝 - Permits API access only from trusted IP addresses.~~
-> 9. ~~Logging and Monitoring 🖥️ - Keeps detailed logs and regularly monitors APIs.~~
->10. ~~Rate Limiting ⏱️ - Limits user requests to prevent overload.~~
->11. Secure Dependencies 📦 - Ensures third-party code is free from vulnerabilities.
->12. Security Headers 📋 - Enhances site security against types of attacks like XSS.
->13. Token Expiry ⏳ - Regularly expiring and renewing tokens prevents unauthorized access.
->14. Use of Security Standards and Frameworks 📘 - Guides your API security strategy.
->15. Web Application Firewall 🔥 - Protects your site from HTTP-specific attacks.
->16. API Versioning 🔄 - Maintains different versions of your API for seamless updates.
->
->This week, we will look at the remaining practices.
+>[Last week](https://blog.frankel.ch/secure-api-practices-apisix/1/), we listed 16 practices to help secure one's APIs and described how to implement them with Apache APISIX. This week, we will look at the remaining practices.
 
 <!--truncate-->