Refactor code structure for improved readability and maintainability

Author: addavid888

content/3-BlogsTranslated/3.1-Blog1/_index.md

@@ -20,7 +20,7 @@ Many organizations require dynamic API routing capabilities to support their evo
 
 With this new launch, you can implement dynamic routing logic with a simple declarative configuration within the custom domain name settings. The new routing rule mechanism allows you to make routing decisions based on HTTP headers, base paths, or a combination of both. Developers are no longer required to create new or alter existing paths to smoothly transition between API versions, they can simply specify the desired value in the request HTTP header. Among other possibilities, you can implement cell-based architecture routing, A/B testing, or dynamic backend selection based on [hostname](https://docs.aws.amazon.com/apigateway/latest/developerguide/how-to-custom-domains.html#wildcard-custom-domain-names), tenant ID, accepted response media type, or cookie value. By implementing routing logic directly within the API Gateway, you can eliminate proxy layers and complex URL structures while maintaining fine-grained control over your API traffic. This new feature seamlessly integrates with existing API Gateway capabilities and supports both public and private REST APIs. The following diagram shows how you can use routing rules for header and base-path based routing. This example uses a single level resource /products to show path matching, however depending on your use-case you could also use multi-level paths like **/products/items**.
 
-![image-1](images/3-BlogsTranslated/3.1-/image-1.png)
+![image-1](images/3-BlogsTranslated/3.1-/image-1.jpg)
 
 Figure 1. Using routing rules for header and base-path based routing
 
@@ -122,7 +122,7 @@ For scenarios like API versioning, you can create rules that evaluate headers su
 
 Header-based routing also simplifies A/B testing by allowing you to define client cohorts based on custom headers, allowing controlled experiments with different configurations. You can create rules that check for a custom header like **“x-test-group”** to route specific users to different API implementations. The priority system ensures predictable routing behavior – when multiple rules match a request, the rule with the lowest priority number (highest precedence) determines the routing. Combining header and path conditions within a single rule enables complex routing scenarios such as version-specific routing for specific API resources instead of the entire API, as illustrated in the following diagram.
 
-![image-2](images/3-BlogsTranslated/3.1-/image-2-1.png)
+![image-2](images/3-BlogsTranslated/3.1-/image-2-1.jpg)
 
 Figure 2. A routing configuration with two header and one path conditions in API Gateway Console.
 

content/3-BlogsTranslated/3.2-Blog2/_index.md

@@ -82,125 +82,4 @@ Figure 10: Summary of changes and suggestions
 
 **Conclusion**
 
-The addition of Amazon Q Developer’s agentic experience in Microsoft Visual Studio and JetBrains IDEs takes Amazon Q Developer beyond traditional chat-based interactions to intelligent, action-oriented assistance. The ability to automatically read files, generate code diffs, run shell commands, and validate changes demonstrates a level of autonomy that can significantly accelerate development tasks while maintaining code quality. The examples we’ve explored, from automated test creation to build error resolution, showcase how the agentic experience can streamline common development tasks that traditionally required multiple manual steps. This new capability, combined with multi-language support and customizable development standards, makes Amazon Q Developer a powerful ally in modern software development workflows. As development teams continue to seek ways to improve productivity without compromising code quality, Amazon Q Developer’s agentic experience represents a meaningful step forward in IDE-integrated AI assistance. Whether you’re writing tests, fixing bugs, or optimizing code, the ability to have an AI assistant that can not only suggest solutions but also implement them while maintaining context awareness is a game-changing addition to the developer’s toolkit.
-
-
-
-
-
-
-
-
-Data lakes can help hospitals and healthcare facilities turn data into business insights, maintain business continuity, and protect patient privacy. A **data lake** is a centralized, managed, and secure repository to store all your data, both in its raw and processed forms for analysis. Data lakes allow you to break down data silos and combine different types of analytics to gain insights and make better business decisions.
-
-This blog post is part of a larger series on getting started with setting up a healthcare data lake. In my final post of the series, *“Getting Started with Healthcare Data Lakes: Diving into Amazon Cognito”*, I focused on the specifics of using Amazon Cognito and Attribute Based Access Control (ABAC) to authenticate and authorize users in the healthcare data lake solution. In this blog, I detail how the solution evolved at a foundational level, including the design decisions I made and the additional features used. You can access the code samples for the solution in this Git repo for reference.
-
----
-
-## Architecture Guidance
-
-The main change since the last presentation of the overall architecture is the decomposition of a single service into a set of smaller services to improve maintainability and flexibility. Integrating a large volume of diverse healthcare data often requires specialized connectors for each format; by keeping them encapsulated separately as microservices, we can add, remove, and modify each connector without affecting the others. The microservices are loosely coupled via publish/subscribe messaging centered in what I call the “pub/sub hub.”
-
-This solution represents what I would consider another reasonable sprint iteration from my last post. The scope is still limited to the ingestion and basic parsing of **HL7v2 messages** formatted in **Encoding Rules 7 (ER7)** through a REST interface.
-
-**The solution architecture is now as follows:**
-
-> *Figure 1. Overall architecture; colored boxes represent distinct services.*
-
----
-
-While the term *microservices* has some inherent ambiguity, certain traits are common:  
-- Small, autonomous, loosely coupled  
-- Reusable, communicating through well-defined interfaces  
-- Specialized to do one thing well  
-- Often implemented in an **event-driven architecture**
-
-When determining where to draw boundaries between microservices, consider:  
-- **Intrinsic**: technology used, performance, reliability, scalability  
-- **Extrinsic**: dependent functionality, rate of change, reusability  
-- **Human**: team ownership, managing *cognitive load*
-
----
-
-## Technology Choices and Communication Scope
-
-| Communication scope                       | Technologies / patterns to consider                                                        |
-| ----------------------------------------- | ------------------------------------------------------------------------------------------ |
-| Within a single microservice              | Amazon Simple Queue Service (Amazon SQS), AWS Step Functions                               |
-| Between microservices in a single service | AWS CloudFormation cross-stack references, Amazon Simple Notification Service (Amazon SNS) |
-| Between services                          | Amazon EventBridge, AWS Cloud Map, Amazon API Gateway                                      |
-
----
-
-## The Pub/Sub Hub
-
-Using a **hub-and-spoke** architecture (or message broker) works well with a small number of tightly related microservices.  
-- Each microservice depends only on the *hub*  
-- Inter-microservice connections are limited to the contents of the published message  
-- Reduces the number of synchronous calls since pub/sub is a one-way asynchronous *push*
-
-Drawback: **coordination and monitoring** are needed to avoid microservices processing the wrong message.
-
----
-
-## Core Microservice
-
-Provides foundational data and communication layer, including:  
-- **Amazon S3** bucket for data  
-- **Amazon DynamoDB** for data catalog  
-- **AWS Lambda** to write messages into the data lake and catalog  
-- **Amazon SNS** topic as the *hub*  
-- **Amazon S3** bucket for artifacts such as Lambda code
-
-> Only allow indirect write access to the data lake through a Lambda function → ensures consistency.
-
----
-
-## Front Door Microservice
-
-- Provides an API Gateway for external REST interaction  
-- Authentication & authorization based on **OIDC** via **Amazon Cognito**  
-- Self-managed *deduplication* mechanism using DynamoDB instead of SNS FIFO because:  
-  1. SNS deduplication TTL is only 5 minutes  
-  2. SNS FIFO requires SQS FIFO  
-  3. Ability to proactively notify the sender that the message is a duplicate  
-
----
-
-## Staging ER7 Microservice
-
-- Lambda “trigger” subscribed to the pub/sub hub, filtering messages by attribute  
-- Step Functions Express Workflow to convert ER7 → JSON  
-- Two Lambdas:  
-  1. Fix ER7 formatting (newline, carriage return)  
-  2. Parsing logic  
-- Result or error is pushed back into the pub/sub hub  
-
----
-
-## New Features in the Solution
-
-### 1. AWS CloudFormation Cross-Stack References
-Example *outputs* in the core microservice:
-```yaml
-Outputs:
-  Bucket:
-    Value: !Ref Bucket
-    Export:
-      Name: !Sub ${AWS::StackName}-Bucket
-  ArtifactBucket:
-    Value: !Ref ArtifactBucket
-    Export:
-      Name: !Sub ${AWS::StackName}-ArtifactBucket
-  Topic:
-    Value: !Ref Topic
-    Export:
-      Name: !Sub ${AWS::StackName}-Topic
-  Catalog:
-    Value: !Ref Catalog
-    Export:
-      Name: !Sub ${AWS::StackName}-Catalog
-  CatalogArn:
-    Value: !GetAtt Catalog.Arn
-    Export:
-      Name: !Sub ${AWS::StackName}-CatalogArn
+The addition of Amazon Q Developer’s agentic experience in Microsoft Visual Studio and JetBrains IDEs takes Amazon Q Developer beyond traditional chat-based interactions to intelligent, action-oriented assistance. The ability to automatically read files, generate code diffs, run shell commands, and validate changes demonstrates a level of autonomy that can significantly accelerate development tasks while maintaining code quality. The examples we’ve explored, from automated test creation to build error resolution, showcase how the agentic experience can streamline common development tasks that traditionally required multiple manual steps. This new capability, combined with multi-language support and customizable development standards, makes Amazon Q Developer a powerful ally in modern software development workflows. As development teams continue to seek ways to improve productivity without compromising code quality, Amazon Q Developer’s agentic experience represents a meaningful step forward in IDE-integrated AI assistance. Whether you’re writing tests, fixing bugs, or optimizing code, the ability to have an AI assistant that can not only suggest solutions but also implement them while maintaining context awareness is a game-changing addition to the developer’s toolkit.